ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Метки статьи: ‘ripe’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Думаю многим из вас знаком сайт http://www.robtex.com на котором много полезных вещей и одна из них это графическое отображение связей заданной AS.

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

Но есть вещи которых нет в графическом отображении  www.robtex.com. Например он не показывает даунстримов (клиентов) для заданной AS. Соответственно нет инфы, которая нужна админу транзитного оператора, который настраивает фильтры под клиентов. Инфа бы помогла увидеть «кольца» в маршрутизации его клиентов через другие связанные с ним AS.

Так же что-то непонятное творится с кешированием. Много раз замечал на AS`ках, которых обслуживаю, что инфа на www.robtex.com не соответствует текущей ситуации иногда даже через месяц после изменений. Т.е. ты что-то поменял, но измений не видно… и долго не видно.

На просторах «тырнета» была обнаружена либа «JavaScript Graph Library» -> Dracula Graph Library, которая отображает связности между объектами.

Dracula Graph Library работает на векторной библиотеке Raphaël, разработанной  Дмитрием  Барановским.

То что нам и надо. Большое спасибо разработчикам данных либ, очень сильно помогли и сэкономили кучу времени.

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

Итак, готовы вам представить первую версию собственного скрипта отображающий инфу по AS в графическом виде —>  «Построение графа связанности AS по ее номеру«.

Где можно указать номер AS, а так же:

  • тип выводимой информации: апстримы/даунстримы
  • выбрать глубину рекурсии

Вся информация берется из БД RIPE, которая доступна в выводе информации по номеру AS: http://www.db.ripe.net/whois?ASXXXXX (где XXXXX номер AS).

Пример вывода скрипта по нашей AS:

AS graph example

AS graph example

  • Красные стрелочки -> Апстримы
  • Зеленые стрелочки -> Даунстримы

Как вы понимаете автономка автономке рознь, т.е. кол-во апстримов и даунстримов у крупного оператора может быть большим, поэтому во избежание зависания вашего браузера выставлен лимит по кол-ву отображаемых на экране объектов, в 200 шт.

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

Посему кеш у нашей тулзы тоже есть, но он не такой «жестокий» и составляет не более 3-х суток.

Не всегда расположение объектов на странице вывода является оптимальным, для этого в конце страницы есть кнопка «перерисовать», либо вы сами можете  таскать любой объект (круг с номером AS) на экране и расставить их так, как нравится вам.

Информация заносимая админами в описание их AS в БД RIPE может различаться, т.к. способов написания import/export несколько. Мы постарались учесть самые распространенные из них, но мы предполагаем, что вы, уважаемые посетители, можете найти AS, картинка по которой может отображаться не совсем правильно. Если это так, то просим Вас сообщить нам о такой через форму «обратной связи» у нас на сайте.

И опережая вопросы: ДА, мы думали над тем, что бы брать информацию не из БД RIPE, а непосредственно из таблицы маршрутизации (full-view) BGP роутеров. Возможно, мы сделаем это в следующих версиях скрипта когда руки дойдут :)

По мере использования, получения отзывов и предложений наша тулза может изменяться.

Надеемся, что эта тулза поможет не только нам, поэтому и решили разместить её на нашем сайте в свободном доступе :)

Автор: Панфилов Алексей (lehis (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 4,00 из 5)
Loading...Loading...
Отправить на почту Отправить на почту

Все вы, у кого есть своя ASка, получили письмо от RIPE:

From: Andrew de la Haye <noreply@ripe.net>
Subject: 32-bit AS Numbers: A Change Is Coming!

Dear Colleagues,

As of 1 January 2009, the RIPE NCC will begin assigning 32-bit (or four-byte) ASN Numbers (ASNs) by default. This is in accordance with a global
policy agreed on in all Regional Internet Registry (RIR) communities.

When requesting an ASN after 1 January, LIR staff should ensure that 32-bit ASNs will be compatible with their existing networks. Some network
operators may experience difficulties configuring BGP sessions if their or their upstream providers' equipment is not compliant with the new
32-bit standard.

If you believe your network will encounter problems with 32-bit ASNs, it will be possible to specifically request a 16-bit ASN.

For more information, please see, "32-bit Autonomous System Numbers: A Guide for LIRs":
http://www.ripe.net/news/asn-32-guide.html

If you have any questions regarding 32-bit ASNs, please send an email to <contact@ripe.net>.

Regards,
Andrew de la Haye
Chief Operations Officer, RIPE NCC

Один знакомый бросил ссылочку на интересную статейку и мы решили запостить и у нас:

Understanding 4-Byte Autonomous System Numbers

For all the harping I do on this blog about IPv4 address depletion and the need to prepare yourselves for IPv6, there is another number resource that is also being quickly depleted, and that I haven’t written about before: the 2-byte autonomous system numbers (ASNs).

A 16-bit number space gives you 65,536 possible numbers (AS numbers 0 – 65535). Out of these, the IANA reserves 1,026 of them: 64512 – 65534 for private, reusable ASNs (similar to private RFC1918 IPv4 addresses) and a few others such as 0 and 65535 and one that is important to this article, 23456. Presently 49,150 ASNs have been allocated out of the public pool, so there are 15,360 available ASNs remaining: About 23.8 percent of the public pool.

An analysis of the allocation rate of 2-byte ASNs shows that the available pool will run out in mid-2011. Eerily close to the date that we will run out of IPv4 addresses.

Fortunately there is much less cause for concern about ASN depletion than about IPv4 depletion, for two reasons:

  • Unlike IP addresses, which are necessary for anyone that wants to connect to an IP network, autonomous system numbers matter only to networks that are running BGP.
  • Just as IPv6 was created to solve the IPv4 problem by offering an address size four times as large, 4-byte ASNs have been created to solve the 2-byte ASN depletion problem. But where transition to IPv6 can be complicated because of lack of interoperability between IPv4 and IPv6, the transition to 4-byte ASNs is far simpler.

This post describes the format of the 4-byte ASN, how it interoperates with 2-byte ASNs, and what you need to do (if anything) to prepare your network for them.

The 4-Byte ASN Format

4-byte ASNs provide 232 or 4,294,967,296 autonomous system numbers ranging from 0 to 4294967295. The first thing to notice about these numbers is that they include all of the older 2-byte ASNs, 0 through 65535. That greatly helps with interoperability between autonomous systems using 2-byte ASNs and those using 4-byte ASNs. (An oft-heard complaint about IPv6 is that interoperability with IPv4 could have been more easily supported if 4.3 billion IPv6 addresses had been reserved as representative of the existing IPv4 addresses, but that’s another story.)

A 4-byte ASN between 0 and 65535 is called a mappable ASN, because it can be represented in just 2 bytes; the first 16 bits are in every case all zeroes.

Stemming from a concern that 32-bit ASNs might be difficult to write and manage, there are three ways of representing 4-byte ASNs:

· asplain is a simple decimal representation of the ASN, from 0 to 4294967295.

· asdot+ breaks the number up into low-order and high-order 16-bit values, separated by a dot. All of the older 2-byte ASNs can be represented in the low-order value, with the high-order value set to 0. So for example, 65535 is 0.65535. One more than that, 65536, is outside the value that can be represented in the low-order range alone, and is therefore represented as 1.0. 65537 would be 1.1, 65680 is 1.144, and so on. You can figure the low- and high-order values by subtracting multiples of 65,536 from the asplain representation of the ASN, with the high-order value representing the multiples of 65536. The ASN 327700, then, is 5.20: Five times 65536 plus 20 more. The largest ASN, 4294967295, is 65535.65535: 65,535 times 65535, plus 65535 more.

· asdot is a mixture of asplain and asdot+. Any ASN in the 2-byte range of 0 – 65535 is written in asplain (so 65535 is written “65535”) and any ASN above that range is written in asdot+ (so 65536 is written “1.0”).

Asplain is obviously the most straightforward method of understanding the new ASNs, although the larger numbers might become unwieldy to write and therefore prone to typographical mistakes in written documentation or router configurations.

Asdot+ is much simpler to write, but harder to calculate from its simple decimal equivalent. If you work in this format regularly, it’s probably worth your time to write a simple script that does the conversions for you to prevent calculation errors.

Asdot might appear to have limited usefulness. After all, it’s not any harder to write “0.3657” than to write “3657”, and the need to do some calculations come in when you go above 65535; asdot does nothing to help you there. There is, however, a subtlety to this. The regional number assignment authorities – the Regional Internet Registries, or RIRs – differentiate a 16-bit number that is an older 2-byte ASN and a mappable 4-byte ASN (again, the set of 32-bit ASNs in which the first 16 bits are all 0). So “3657” is a 2-byte ASN, and “0.3657” is a 4-byte ASN.

This, of course, leads us to look briefly at just what the RIRs’ policies are for assigning 4-byte ASNs.

ASN Allocation Policies

All five of the RIRs (AfriNIC, APNIC, ARIN, LACNIC, and RIPE NCC) have the same assignment policies for 4-byte ASNs:

· 4-byte ASNs have been available since 1 January 2007. The default assignment, if you request an ASN, is to give you a 2-byte ASN and only assign a 4-byte ASN if you specifically request it.

· Beginning on 1 January 2009 (yes, about a month from now!) that policy reverses: A 4-byte ASN will be the default. You can still get a 2-byte ASN, but only if you specifically request it.

· A year later, on 1 January 2010, all ASN assignments will be 4-byte. The ASN you receive might be of the form 0.XX (where the high-order 16 bits are all 0 and the low-order 16 bits are not), but the RIRs will make no distinction between those numbers and any other 4-byte ASN. And although it won’t effect your network in any way, the 16-bit ASN you’ve had maybe for years will, in the eyes of the RIRs, be a mapable 32-bit ASN. For instance, Level3 Communications’ AS3356 becomes in the eyes of the RIRs, at the beginning of 2010, 0.3356.

These policies raise several questions:

· If you plan to request a new ASN assignment starting in 2009, what do you need to do to prepare for it?

· How do the new 4-byte ASNs interoperate with older autonomous systems using 2-byte ASNs?

· If you have an existing 2-byte ASN, does anything change?

The ASN’s Role in BGP

A brief review of how BGP uses autonomous system numbers will help in understanding how the new format might impact BGP networks. Most of you already know the basics of BGP; if you do, feel free to skip ahead.

The purpose of BGP, unlike any IGP (OSPF, IS-IS, EIGRP and RIP), is to route between domains under separate administrative control – that is, systems that are autonomous from each other. If you’re going to route between (and among) these autonomous routing domains, you need some way of identifying individual ASs. That identifier is the autonomous system number.

The ASN has two essential functions in BGP:

First, it helps BGP determine the shortest path to a destination. When BGP advertises a route to a neighbor in an Update message, it attaches several path attributes to the route. When a router learns more than one BGP route to the same destination, the BGP decision process evaluates the routes’ path attributes in a prioritized order to decide which of the routes is most preferable. (BGP path attributes can be added, removed, or changed in all sorts of ways to influence the BGP decision process. This is the basis for BGP routing policies.) One of these attributes, attached to every BGP route, is called AS_PATH. When a router advertises a destination within its own AS to a neighbor in another AS, it puts its local ASN in the AS_PATH. As the route is advertised to subsequent autonomous systems, each AS border router adds its own ASN to the attribute. The AS_PATH, then, becomes a list of ASNs that describes the path back to the destination. A router can choose a shortest path by choosing the route with the fewest ASNs listed in its AS_PATH.

The second ASN function is a very simple loop avoidance mechanism. Because a router adds its ASN to the AS_PATH before advertising a route to a neighbor in another AS, a route that loops – that is, exits an AS and is subsequently advertised back to the same AS – is easily detected by examining the AS_PATH. If a router sees its own ASN listed in the AS_PATH of a route advertised to it by a neighbor, it drops the route.

The ASN also appears in a path attribute called the AGGREGATOR. When a number of routes are summarized (aggregated), route details can be lost. The AGGREGATOR attribute can be added to an aggregate route to indicate the Router ID and ASN of the router performing the aggregation. This attribute does not influence the BGP decision process, but it can be useful for tracing back problems with aggregate routes.

A third attribute that uses the ASN is COMMUNITIES. This optional attribute helps you manage routing polices when they apply to a large number of routes; using a number of methods you can assign one or more COMMUNITIES attributes to prefixes, and then apply a routing policy to a community rather than individual routes. For example, you might define a COMMUNITES attribute named Cust_Routes and then add that attribute to all routes advertised into your AS by all your customers. Then anywhere in your network that you need to apply a policy to all of your customer routes, you can apply the policy to routes having the Customer_Routes attribute rather than having to identify each prefix (and possibly change all your prefix lists any time a customer route is added or removed).

The COMMUNITES attribute is a 32-bit value in which the first 16 bits are an ASN and the last 16 bits are arbitrarily assigned by you to have whatever meaning you want.

The important point here is not so much the functions of AGGREGATOR or COMMUNITES, however, but that they, like AS_PATH, are formatted to carry 2-byte ASNs; the formats of these attributes must therefore be adapted to carry the larger 32-bit ASNs.

In addition to these three path attributes the BGP Open message also references the ASN, in a 16-bit field called My Autonomous System. BGP runs on top of a TCP session between neighbors; after the TCP session is established, the neighbors use Open messages to negotiate the BGP session. Each neighbor indicates its Router ID, ASN, the BGP version it is running (always version 4 in modern networks), its hold time (the time it expects to wait for a Keepalive from the neighbor before closing the session) and possibly some optional parameters.

There is alot more to BGP than what has been described here. What is important for this discussion is that there are four BGP data entities that carry ASNs:

· The AS_PATH attribute;

· The AGGREGATOR attribute;

· The COMUNITES attribute; and

· The Open message

Consideration must be given to each of these entities not only in terms of adapting them to 4-byte ASNs but also making the adaptations interoperable with older BGP implementations that only understand 2-byte ASNs.

Neighbor Interoperability

For simplicity, we’ll call BGP implementations supporting 4-byte ASNs New_BGP, and legacy BGP implementations that only support 2-byte ASNs Old_BGP.

The first requirement for a New_BGP implementation is to discover whether a neighbor is New_BGP or Old_BGP. It does this by using the BGP Capability Advertisement when opening a BGP session. In addition to advertising itself as New_BGP, it includes its 4-byte ASN in the Capability advertisement.

If a neighbor responds that it also is a NEW_BGP speaker, the neighbor includes its 4-byte ASN in its own Capability advertisement. Thus two New_BGP neighbors can inform each other of their 4-byte ASNs without using the 2-byte My Autonomous System field in the Open message. (If the neighbors are NEW_BGP but have 2-byte ASNs or mappable 4-byte ASNs, they can still put the ASN in the My Autonomous System field in addition to the Capability advertisement.)

If a neighbor is Old-BGP, it either responds that it does not support the 4-byte ASN capability or does not respond to the Capability advertisement at all. In this case, the New_BGP neighbor can still bring up a session with the Old-BGP neighbor, but cannot advertise its 4-byte ASN. The neighbor wouldn’t understand it. Instead, New_BGP uses a reserved 2-byte ASN, 23456, called AS_TRANS (AS_TRANS is easily remembered because of its 2-3-4-5-6 sequence). This AS number is added to the My Autonomous System field of the Open message. Because AS_TRANS is reserved, no Old_BGP speaker can use it as its own ASN; only New_BGP speakers can use it.

Interoperable peering, then, is achieved because the New_BGP speaker “knows” its neighbor is an Old_BGP speaker and adapts to it; the Old-BGP speaker simply continues using legacy BGP rules.

Path Attribute Interoperability

Because the New_BGP speaker knows whether its neighbor is New_BGP or Old_BGP, it knows what rules to follow when advertising routes to the neighbor.

When advertising routes to a New_BGP neighbor, the AS_PATH attribute is simply modified to carry 4-byte ASNs. But when advertising routes to an Old-BGP neighbor, the AS_PATH must be kept in its legacy format, as a list of 2-byte ASNs; an Old_BGP neighbor would not otherwise know how to interpret the list. Rather than adding its own 4-byte ASN to the AS_PATH, the New_BGP speaker adds the AS_TRANS (again, AS23456) to the AS_PATH as a placeholder for its own and any other 4-byte ASNs appearing on the path. The router also adds a new attribute, AS4_PATH, to the route. This attribute carries the list of real ASNs, both 4-byte and 2-byte. Unlike AS_PATH, which is a mandatory attribute for all routes, AS4_PATH is optional transitive: “Optional” meaning it is only used when needed (and in fact a New_BGP speaker will not use this attribute if the AS_PATH is all 2-byte ASNs), and “transitive” meaning any BGP speaker passes the attribute along to other neighbors even if it doesn’t understand the attribute. Thus, the real autonomous system path can be passed transparently through one or more Old_BGP speakers.

When an Old_BGP speaker advertises a route with both AS_PATH and AS4_PATH attributes to a New_BGP speaker, the New_BGP speaker uses both attributes to reconstruct the path: AS4_PATH to find 4-byte ASNs on the path, and AS_PATH to find any 2-byte ASNs Old_BGP speakers will have added since the path last passed through a New_BGP speaker.

By adding AS_TRANS to the AS_PATH as a placeholder for any 4-byte ASNs along the route, the AS_PATH continues to accurately indicate the number of AS hops along the path, and therefore preserves its role in the BGP decision process. And although the AS_TRANS might wind up appearing multiple times in the AS_PATH, that ASN only has meaning to a New_BGP speaker – which will also use the AS4_PATH to reconstruct the path – so the loop avoidance function is also preserved: If a loop occurs, the New_BGP speaker using a 4-byte ASN will find its ASN in the AS4_PATH and drop the route.

The AGGREGATOR attribute, when it is needed, is modified similarly. A New_BGP speaker advertising a route to a New_BGP neighbor simply uses a modified version of the attribute that can carry a 4-byte ASN. If a New_BGP speaker advertises a route with the attribute to an Old_BGP speaker, and if the attribute contains a 4-byte ASN, the New_BGP speaker replaces the ASN with AS_TRANS and puts the real ASN in a new optional transitive attribute called AS4_AGREGATOR.

A New_BGP speaker receiving a route with AGGREGATOR and AS4_AGGREGATOR attributes from an Old_BGP neighbor replaces the AS_TRANS in the AGGREGATOR with the real 4-byte ASN in the AS4_AGGREGATOR.

BGP communities are supported in 4-byte ASN environments by using a new Extended Community attribute called the 4-Octet AS Specific BGP Extended Community (EXT_COMM). This Extended Community consists of a 4-byte ASN and a 2-byte arbitrary number; that is, the format is the same as the legacy COMMUNITIES attribute except the ASN part is 4 bytes instead of 2 bytes.

Preparing Your Network (Or Not)

All this interoperability that I’ve spent so many paragraphs describing to you means that New_BGP is backwards compatible with Old_BGP. This is good news if you currently run a network with a 2-byte ASN: You don’t need to do very much, at least in the near term, to get ready for 4-byte ASNs. Your AS will continue running just fine, even when New_BGP neighbors start peering with it.

If you will be acquiring a new ASN any time after the end of 2008 – and especially after the end of 2009 – there are a few things you will need to do to get your network ready for 4-byte ASNs.

First, of course, you need to insure that your router operating system supports New_BGP. Right now (the end of November 2008) the best information I can find is that the following OSs have New_BGP:

· Cisco Systems IOS-XR 3.4 and later (CRS only)

· Cisco Systems IOS-NX (“Nexus”)

· Cisco Systems IOS 12.2SRD for 7200 and 7600

· Cisco Systems IOS 12.5T for 1800/2800/3800, 7200, 7300

· Cisco Systems 12.2SB-Rel6 for 7200, 7300, 10000

· Cisco Systems 12.2SX for 6500

· Force 10 Networks FTOS 7.7.1.0 and later

· Juniper Networks’ JUNOS 9.1 and later

· Juniper Networks’ JUNOSe 4.1.0 and later

· OpenBGPD 3.9 and later

· Quagga 0.99.6 and later

· Redback SEOS (all versions)

Finding specifics of feature support on most any vendor’s website is like a hunt for buried treasure but seldom with a reward at the end, so if you know of other operating systems supporting New_BGP – or have corrections to my list here – please do post a comment. If unsure about your own network, check with your vendor representative.

The biggest challenge with upgrading to New_BGP is that by far the largest installed base of router operating systems is Cisco IOS, and as you can see from the list above the current IOS support is all in early technology (T) or service provider (S) releases, and restricted to certain platforms. Hopefully New_BGP finds its way into mainstream IOS code in early 2009.

Other aspects of your network operations that should be assessed for support of the new ASNs are:

· Any address management applications that reference the ASN

· Any BGP analysis or traffic engineering applications

· Potential effects on MPLS-based VPNs that use Route Distinguishers

· Applications that use Internet Route Registries (IRRs) to set or publish policies

· Routing policies that reference ASNs such as AS path filters and community lists

Do Autonomous Systems with 2-Byte ASNs Need to Do Anything?

As I said, if you currently run a network with a 2-byte ASN your network will continue running with no problems. But there is one thing you should do in the short term to prepare: You will see more and more instances of AS_TRANS making their appearance in AS_PATHs, and if you are a service provider multiple customers might begin peering with you using AS_TRANS. You need to be sure that your operators and troubleshooters know what this special ASN is, and that multiple instances of it in a single AS_PATH or multiple customers peering to you using it are not indicative of a problem.

For the longer term, it is a good idea to put New_BGP capability on your list of requirements as you plan for router operating system upgrades. You can upgrade to New_BGP router by router without effecting your network. Once all of your routers support 4-byte ASNs, you should convert your 2-byte ASN to the 4-byte 0.XX format.

Taking these steps will save you some future headaches by eliminating potential confusions caused by AS_TRANS, giving you clearer visibility to newer peers and across AS paths, improving your routing policy capabilities, and preventing roadblocks when you need to exchange EXT_COMM attributes with New_BGP peers.

Like IPv6, 4-byte ASNs are the future of the Internet. Although all 2-byte ASNs allocated before 2010 will continue to exist, they will eventually be just a part of the new 32-bit format rather than a separate type of autonomous system number.

Everyone should give some thought now to what you need to do to be prepared for this.

Оригинал статьи

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 2, среднее: 5,00 из 5)
Loading...Loading...
Отправить на почту Отправить на почту

object mntner, object as-set, object aut-num, object route
object inetnum, object person, object domain, object role

Раз вы добрались до конфигурации протокола BGP значит «общения» с базой данных (далее просто «БД«) RIPE вам не избежать.

Многие спрашивают: «А что такое as-set ?» или «Как узнать какой AS принадлежит маршрут

В этой статье я попытаюсь рассказать о том, какие объекты в этой БД вам необходимы для запуска и как они используются.

Итак, вы прошли процесс получения статуса LIR, собственного блока IP-адресов и номера автономной системы (ASNum).

Справка:

Локальный Интернет-реестр (LIR – Local Internet Registry) – термин, используемый для описания членов RIPE NCC.

Их называют локальными Интернет-реестрами (LIR) потому что они несут ответственность за распределение адресного пространства и регистрацию адресного пространства на локальном уровне.Локальные Интернет-реестры также утверждают общеобязательные политики и процедуры на локальном уровне. Организации, которые становятся локальными Интернет-реестрами — это в основном Интернет-провайдеры (ISP), которые выделяют и назначают адресное пространство своим клиентам, телекоммуникационные организации и коммерческие предприятия наряду с академическими учреждениями. Академические учреждения – это организации, которым требуются большие блоки адресного пространства, которые не могут быть получены у вышестоящего провайдера.

Что же делать дальше ? Бесконечное кол-во документации на сайте RIPE и молчащий google… а разбираться нужно. Попробую своими словами описать, то как разбирался/делал я сам.

ALLOCATION vs ASSIGNMENT

Для начала разберем два понятия:

  1. ALLOCATION — выделенное провайдеру адресное пространство. Оно закреплено за ним в БД
  2. ASSIGNMENT — текущее, одобренное RIPE, используемое провайдером адресное пространство так же описанное в БД

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

После того как RIPE сделал ALLOCATION какого либо блока вам необходимо согласовать с ними сколько и под какие нужды вы будете использовать адресное пространство. Вам придется заполнять форму в которой расписывать ADDRESS PLAN, что бы перевести часть адресного пространства из статуса ALLOCATED в статус ASSIGNED. Статус ASSIGNED будет означать, что RIPE одобрил вам использование адресного пространства под описанные вами нужды.

Советы по заполнению ADDRESS PLAN:

  1. не указывайте сети под конечного пользователя более чем /30, т.к. иначе RIPE напишет вам, сеть более чем /30 считается как End User`s infrastructure и заставит ваших пользователей так же заполнять форму на выделение адресного пространства.
  2. можно просить как минимум /24 под P2P (сети /30), в которые будут входить ваши каналы
  3. так же две сети /24 можно попросить под активное оборудование: маршрутизаторы, сервера, voip железки и прочее, главное не переборщите.
  4. RIPE очень любит когда пишут про NAT (адресное пространство ipv4 стремительно заканчивается), не разочаровывайте их, просите, опять таки не менее /24, под NAT сервера.
  5. В кач-ве оборудования пишите все: сервера, циски (даже Catalyst), VoIP шлюзы, железные firewall`ы вообще все что можно :), все для чего можно доказать необходимость внешнего адреса (если спросят ;))

Вы заполнили ADDRESS PLAN и отправили его в RIPE… ждем ответа… варианта два:

  1. их удовлетворит ваш запрос и они выставят статус ASSIGNED PA на сети которые они одобрили
  2. скажут что именно их не устраивает и вам придется бодаться с ними далее.

Зачем все это ? Можете ли вы использовать адресное пространство в статусе ALLOCATED ?

Использовать то вы его сможете, но если у вас кончится адресное пространство и вы заходите получить ещё блок адресов, то RIPE откажет вам, сославшись на то, что вы в текущий момент не используете свой первый ALLOCATED блок адресов. Посмотреть как RIPE видит текущее ваше использование выделенного вам адресного пространства можно с помощью утилиты Web Asused, указав свой Regid (например: ru.myisp) вам на email (указанный в lirportal) придет письмо содержащие отчет об использовании вами вашего адресного пространства.

Объекты в БД

БД состоит из многих объектов, мы рассмотрим некоторые из них. Для примера возьмем хорошего магистрального провайдера: Транстелеком.

Объект person [описание полей объекта]

Это описание человека. Пример:

person:          Yaroslav V Kapsalov
address:         JSC TransTeleCom
address:         7, Dolgorukovskaya st.
address:         127006 Moscow Russia
e-mail:          y.kapsalov@transtk.ru
phone:           +7 495 7846670
nic-hdl:         YARK-RIPE
source:          RIPE # Filtered

Объект person используется для указание административных (admin-c) и технических (tech-c) контактов где необходимо указать NIC-HDL, это уникальный инеднтификатор присваемый объекту person в БД. В данном примере nic-hdl это YARK-RIPE.

Видео пример создания объекта: смотреть

Видео пример проверки объекта: смотреть

Объект role [описание полей объекта]

Похож на объект «person«, но предназначен для описания не только контактного лица, но и роли, которое оно выполняет. Кроме того, объект «role» позволяет объединить несколько персон, выполняющих общую функцию (например отдел тех. поддержки, системных администраторов и т.д.). Для задания административных и технических контактов рекомендуется по возможности применять именно объект «role«. Пример:

role:            TTC NOC
address:         Company TransTeleCom Network Operation Center
address:         7, Dolgorukovskaya st.
address:         127006 Moscow Russia
remarks:         phone:          +7 095 7846677
phone:           +7 495 7846677
remarks:         phone:          +7 095 7846670
phone:           +7 495 7846670
remarks:         fax-no:         +7 095 7846671
fax-no:          +7 495 7846671
............[skiped]....................
mnt-by:          TRANSTELECOM-MNT
source:          RIPE # Filtered
............[skiped]....................

Одноименные поля, заполняются так же, как и в объекте «person«. Обратите внимание, что в отличие от объекта «person» поле «e-mail» здесь является обязательным.

В поле «role» указывается название службы, к которой относится объект.

В полях «admin-c» и «tech-c» указываются nic-handle персон, отвечающих за административные и за технические вопросы. Таких полей может быть несколько.

Объект inetnum [описание полей объекта]

Этот объект описывает ASSIGNMENT блок (блоки, подсети) адресов. Пример:

inetnum:         217.150.32.0 - 217.150.32.255
netname:         TTK-OFFICE-NET
descr:           Transtelecom Office Network
descr:           Moscow, Russia
country:         RU
admin-c:         KTTK-RIPE
tech-c:          KTTK-RIPE
status:          ASSIGNED PA
remarks:         INFRA-AW
mnt-by:          TRANSTELECOM-MNT
source:          RIPE # Filtered

Статус (status)- атрибут объектов inetnum , которые содержат информацию о выделении и назначении пространства IP-адресов (более подробная информация находится в документе ripe-387). В следующей таблицы приведена расшифровка значений статусов блоков IP-адресов.

Статус Пояснение
ALLOCATED PA Данное адресное пространство выделено локальному реестру (LIR), и никакие назначения (assignments) и суб-выделения (sub-allocation) , сделанные в этом пространстве , не являются портабельными (portable) при перемещении (конечного пользователя , которому назначены адреса из этого пространства) к другому провайдеру.
ALLOCATED PI Данное адресное пространство было выделено локальному или региональному реестру , и все назначения , сделанные в нем , портабельны. Назначения (после перемещения к другому провайдеру ) могут быть сохранены так долго , пока выполняются критерии первоначального назначения. Никакие суб-выделения не могут быть сделаны в данном адресном пространстве.
ASSIGNED PA Данное адресное пространство было назначено конечному пользователю для использования с услугами , предоставляемыми соответствующим локальным реестром. Оно не может быть сохранено при отказе от услуг , предоставляемых локальным реестром.
ASSIGNED PI Данное адресное пространство было назначено конечному пользователю и оно может быть сохранено так долго , пока выполняются критерии первоначального назначения
EARLY

REGISTRATION

Адресное пространство с данным статусом используется администрацией базы данных RIPE при перемещении пре-RIR регистраций из базы данных ARIN. Это значение может быть изменено пользователями базы данных (RIPE) (кроме значения ALLOCATED PA) . Объекты с подобным статусом могут создавать только администраторы базы данных RIPE.
NOT-SET Это значение показывает , что соответствующие адресные пространства (точнее , соответствующие объекты типа Inetnum) были зарегистрированы до того , как атрибут «статус» стал обязательным для объектов типа Inetnum. Соответствующий объект не был обновлен с тех пор. Объекты с таким значением статуса не создаются. Данное значение статуса может быть изменено пользователями базы данных.
SUB-ALLOCATED PA Данное адресное пространство было выделено локальным реестром нижестоящему сетевому оператору , который будет (сам) назначать адреса (конечным пользователям) из данного пространства. Все назначения из данного пространства являются PA. Они не могут быть сохранены при смене услуги на другую , предоставляемую другим провайдером.
ALLOCATED UNSPECIFIED Данное адресное пространство выдлено локальному или региональному реестру. Назначения (assignments) могут быть PI и PA . Этот статус предназначен для адресных пространств , выделенных согласно устаревшим на данный момент документам , когда существовали одновременно назначения (assignments) обоих типов. Присваивания данного статуса новым выделенным адресным пространствам избегают. Суб-выделения адресных пространств в данном типе адресного пространства не могут быть совершены.
LIR-PARTITIONED PA Данный статус позволяет локальным реестрам документировать распределение и делегировать управление выделенным пространством внутри своих организаций. Адресное пространство с данным статусом не считается используемым. Когда адреса из такого пространства используются , должен быть зарегистрирован более конкретный объект типа Inetnum для этих адресов.
0 Данный статус не является статусом , официально утвержденным RIPE NCC, значение 0 («нуль») всего лишь отмечает , что статус данного блока адресов неизвестен , это значение используется только данной релизацией базы данных географической привязки


Объект route[описание полей объекта]

Этот объект указывает на то, какой автономной системе принадлежит сеть. Пример:

route:           217.150.32.0/19
descr:           RU-TRANS-TELECOM-20010213
origin:          AS20485
mnt-by:          TRANSTELECOM-MNT
source:          RIPE # Filtered

Из этого следует, что сеть 217.150.32.0/19 оглашается автономной системой с номером 20485. Ключом route объекта являются одновременно два поля: route и origin . В поле route указывается диапазон адресов, за маршрутизацию которых в Интернет будет отвечать автономная система, номер которой указан в поле origin .

Объект aut-num[описание полей объекта]

Этот объект описывает автономную систему. Пример:

aut-num:         AS20485
as-name:         TRANSTELECOM
descr:           JSC Company TransTeleCom
descr:           Moscow, Russia
............[skiped]....................

В нем описывают не только кому принадлежит данный номер, административные и технические контакты,
но и описание пиров (peer) данной автономной системы и комьюнити (communities) которые можно
использовать.
Пиры:
…………[skiped]………………..
import: from AS174 action pref=120; accept AS174:AS-COGENT;
import: from AS786 action pref=120; accept AS-JANETPLUS;
import: from AS1290 action pref=120; accept AS-PSINETUK;
import: from AS2110 action pref=120; accept AS-IEUNET;
import: from AS2119 action pref=120; accept AS-TELENOR;
import: from AS2529 action pref=120; accept AS-DEMON;

…………[skiped]………………..

Показывает импорт маршрутов для автономной системы Транстелекома (AS20485), префиксы каких
автономных систем принимаются от указанных пиров. Может быть указано как и одиночная AS так и as-set.

…………[skiped]………………..

export: to AS174 announce AS-TTK;
export: to AS786 announce AS-TTK;
export: to AS1290 announce AS-TTK;
export: to AS2110 announce AS-TTK;
export: to AS2119 announce AS-TTK;
export: to AS2529 announce AS-TTK;

…………[skiped]………………..

Показывает какие маршруты оглашаются автономной системой Транстелекома (AS20485) своим пирам.
Так же может быть указана одна AS или as-set (в данном примере используется именно as-set)

Комъюнити:
…………[skiped]………………..
remarks: +==============================================================+
remarks: | BGP COMMUNITIES |
remarks: +—————————————————————
remarks: | Communities for prefix classification |
remarks: +—————————————————————
remarks: | All inbound prefixes are marked with BGP communities |
remarks: | which describe their source and geographical region. |
remarks: | The format for the second component of community |
remarks: | (number after 20485:) is set at five digits. |
remarks: | This format is 20485:SNNRR where the fields are: |
remarks: | |
remarks: | S — source of the prefix: |
remarks: | |
remarks: | 1 — Customer |
remarks: | 2 — Upstream |
remarks: | 3 — International peer |
remarks: | 4 — Russian peer |
remarks: | |
remarks: | NN — Upstream, peer or customer number: |
remarks: | |
remarks: | Customers: |
remarks: | 11 — BGP with Internal Internet Access |
remarks: | 13 — BGP with Partial Internet Access |
remarks: | 17 — BGP with Global Internet Access |
remarks: | Static routes from CTTC allocations: 20485:61RR|
remarks: | Upstreams: |
remarks: | 01 — Cable&Wireless (AS1273) |
remarks: | 02 — Telia (AS1299) |
remarks: | 03 — NTT (AS2914) |
remarks: | 05 — PCCW (AS3491) |
remarks: | 07 — UUNET (AS702) |
remarks: | International peers: |
remarks: | 01 — SONG (AS3246) |
remarks: | 03 — GOOGLE (AS15169) |
remarks: | 04 — LINX |
remarks: | 05 — RETN (AS9002, International peers) |
…………[skiped]………………..

Описывает как используются/использовать комъюнити с данной автономной системой.

Комъюнити может выставляться на все маршруты или только на некоторые. Комъюнити состоит из
ASNUM:COMMNUM — номер автономной системы родителя данного комъюнити : 20485:20100
По комъюнити можно понять откуда пришел маршрут и использовать их в своих фильтрах (route-map). Так же с их помощью можно «просить» автономную систему соседа сделать что либо с оглашаемыми вашей AS маршрутами (префиксами).

…………[skiped]………………..
remarks: +—————————————————————+
remarks: | Communities for prefix control |
remarks: +—————————————————————+
remarks: | !!!ATENTION!!! |
remarks: | The using of this communities may cause connectivity |
remarks: | problems and you must clearly understand what you |
remarks: | are doing. TransTeleCom does not bear any responsibility |
remarks: | if there will be such troubles. |
remarks: +—————————————————————+
remarks: | There are two predetermined eBGP session types which |
remarks: | customers may use: |
remarks: | 1 — Global Internet Access. CTTC announce |
remarks: | customer’s prefixes to all customers, |
remarks: | upstreams and peers. |
remarks: | BGP communities are available. |
remarks: | |
remarks: | 2 — Access to customers and Russian peers. |
…………[skiped]………………..
remarks: | — To prepand or deny prefix use 20485:5DNNA, where: |
remarks: | |
remarks: | D — destination of the prepend or deny action: |
remarks: | 2 — Upstreams |
remarks: | 3 — International peers |
remarks: | 4 — Russian peers |
remarks: | 9 — Upstreams and Peers |
…………[skiped]………………..
remarks: | A — action: |
remarks: | |
remarks: | 0 — don’t announce prefix |
remarks: | 1 — announce with one prepend |
remarks: | 2 — announce with two times prepend |
remarks: | 3 — announce with three times prepend |
…………[skiped]………………..

Составив комьюнити, исходя из описания, и, огласив его вместе с исходящим от вас маршрутом(ами), автономная система пира (в данном примере AS20485) выполнит те или иные действия: выполнит prepend (препенд — когда в as-path подставляется N раз ваш номер AS, что увеличивает as-path и соответственно ухудшает маршрут) или вовсе «запретит» (не будет анонсировать своим соседям) этот маршрут (префикс).
Это может позволит вам балансировать входящий трафик на ваших внешних каналах.

Объект as-set[описание полей объекта]

Этот объект описывает (включает в себя) несколько автономных систем или других as-set.

Данный объект используется для настройки входящих BGP фильтров, используются или префиксы или as-path. Пример:

as-set:          AS-TTK
descr:           Customers with TransTeleCom Global Access
members:         AS20485
members:         AS-CTTC
members:         AS-KTTK
members:         AS-SETTC
members:         AS-SIBTTK
members:         AS-STTK
members:         AS-SUTTK
members:         AS-TTKNN
members:         AS-TTKNN-IZHEVSK
members:         AS-UMN
members:         AS-UMN-TMN
members:         AS-VTT
members:         AS-ZSTTK-SET
members:         AS33989
............[skiped]....................
mnt-by:          TRANSTELECOM-MNT
source:          RIPE # Filtered

Внутри объекта as-set member`ом может быть как и одна AS (например AS33989) так и другие as-set`ы (например AS-CTTC). Воспользовавшись утилитой на нашем сайте вы сможете построить фильтры по as-set (внимание ! Объект as-set должен существовать в БД RIPE).

В данном примере имя as-set`а — AS-TTK.

Объект domain[описание полей объекта]

Этот объект отвечает за DNS сервера. Благодаря ему можно указать DNS сервера отвечающие за обратный резолв (PTR записи) для вашего блока адресов. Пример:

domain:          32.150.217.in-addr.arpa
descr:           Reverse delegation for TRANS-TELECOM-NET
remarks:         INFRA AW
admin-c:         KTTK-RIPE
tech-c:          KTTK-RIPE
zone-c:          KTTK-RIPE
nserver:         dns-prim.transtk.ru
nserver:         dns-sec.transtk.ru
nserver:         ns.transtelecom.net
nserver:         ns1.transtelecom.net
mnt-by:          TRANSTELECOM-MNT
source:          RIPE # Filtered

Это необходимо если вы хотите, чтобы на команду nslookup ВАШ-IP-АДРЕС, вы и остальной мир, получали имя.

Пример: nslookup 217.150.32.1
1.32.150.217.in-addr.arpa name = ttk-eth1.transtk.ru.

Объект mntner[описание полей объекта]

Произносится как maintainer.

Этот объект необходим для защиты объектов в БД, основным признаком которого является схема аутентификации. При использовании ссылки на mntner в каком-либо объекте БД (включая сам mntner) объект считается защищенным от несанкционированного изменения/удаления, при этом степень защищенности определяется схемой аутентификации. Им как бы подписывают другие объекты, как сертификатом, подтверждая подлинность данных. В отличие от других объектов, объект mntner имеет пароль и для того, чтобы изменить другие объекты, в которых есть ссылка на mntner (при их создании/редктировании было добавлено поле «mnt-by«), вам необходимо знать его. Кем «подписан» можно видеть по полю mnt-by. Пример:

mntner:          TRANSTELECOM-MNT
descr:           JSC TransTeleCom Maintainer
admin-c:         KTTK-RIPE
tech-c:          KTTK-RIPE
auth:            MD5-PW $1$dkAwA6S5$tP8KkASb5xG7atyTYxpDo/
mnt-by:          TRANSTELECOM-MNT
referral-by:     RIPE-DBM-MNT
source:          RIPE # Filtered

Строка auth и содержит зашифрованный пароль. Пароль криптуется как и в ОС FreeBSD (/etc/master.passwd), поэтому при создании объекта mntner свой пароль можно скопировать из файла /etc/master.passwd лиюо воспользоваться утилитой Crypted password generation на сайте RIPE.

Видео пример создания объекта: смотреть

Обязательно защищайте свои объекты с помощью mntner (поле«mnt-by«). Посмотрите видео пример как это сделать: смотреть

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

Так что дальше ?

Если у вас уже есть номер атономной системы и свой блок адресов, то пора внести в БД недостающие части. Вносить изменения в можно двумя способами:

  1. отправить письмо с полным описанием объекта на email auto-dbm@ripe.net. В ответ вам придет письмо или «SUCCESS: changes» или «FAILED: changes» с описанием ошибок которые вы допустили.
  2. воспользоваться online утилитой Webupdates

На вашем месте я бы сначала пользовался 2-ым способом, т.к. там есть подсказки при создании объектов.

Сначала создадим объект person. Заходим на Webupdates, в разделе «Create a new object» выбираем объект person и жмем «Add object». Заполняем все необходимые поля и жмем «Submit update» и читаем создался ли объект или проишошла какая либо ошибка. Если какие либо поля вызывают сомнения то жмем «?» и читаем описание-подсказку. Поле «nic-hdl» можно выставить в AUTO-1, тогда БД сама сгенерит имя для этого объекта.

Теперь создадим mntner. Опять идем в «ADD» на Webupdates и выбираем объект mntner.

В поле «mntner:» пишем MNTYOUR-PROVIDER-NAME или YOUR-PROVIDER-NAMEMNT.
В поле «admin-c:» пишем nic-hdl (которые мы получили после создания объекта person.) — это будет использоваться для административных контактов.
В поле «auth:» пишем MD5-PW ВАШ-ПАРОЛЬ-В-MD5
В поле «referral-by:» пишем RIPE-DBM-MNT

После создания объекта mntner можно вернуться к объекту person, но уже редактируя, т.е. раздел «Modify or delete an existing object» — вводим свой nic-hdl. В радактировании добавляем поле «mnt-by» (воспользовавшись формой «Add New Field» внизу страницы), в нем указываем имя которое мы писали создавая объект mntner, например MNTYOUR-PROVIDER-NAME, но теперь необходимо добавить поле «password» в котором ввести некриптованый пароль, дабы подтвердить владение объектом mntner. «Подписав» объект person своим объектом mntner вы избегаете того, что кто либо изменит ваш объект person без вашего ведома, т.к. теперь для любого изменения этого обекта будет требоваться пароль mntner`а.

Далее необходимо создать объект inetnum.

В поле «inetnum:» вписываем сеть которую мы согласовали с RIPE когда писали Address Plan. Например: 217.150.32.0 — 217.150.32.255

В поле «netname:» вписываем название для своей сети так же указанную в Address Plan.

В поле «status:» пишем ASSIGNED PA

Что писать в поле «mnt-by:» вы уже знаете 😉

Все остальные объекты создаются/редактируются по тому же принципу.

Создайте объекты route, domain, as-set.

В объекте domain добавте столько полей «nserver:» сколько вам необходимо. В них нужно указать DNS имена ваших DNS серверов которые будут отвечать за reverse delegation (обратный просмотр(резолв)) ваших адресов. В «zone-c:» указываем nic-hdl человека который в вашей организации будет отвечать за зоны обраного просмотра.

В объекте as-set добавте поле «members:». Если ваша AS пока не транзитная, то напишите в нем ASНОМЕР_ВАШЕЙ_AS, поле «as-set:» является именем вашего будущего as-set`а. Обычно имя выглядит как AS-PROVIDER_NAME, например AS-TTK.

Создать его нужно для того, что если вас спросят «По какому объекту строить фильтры ?», то вам необходимо говорить что это as-set и его имя. Это для Вашего же удобства.

Важно: если вы отредактировали свой as-set (добавили/удалили что-то), то вам необходимо сообщить об этом вашим peer`ам (соседям), т.к. не у всех есть автоматический апдейт фильтров.

Отредактируйте (если это необходимо) свой объект aut-num например добавив поле(я) «remarks:» или «descr:» с более подробным описанием своей сети или юр.лица которому она принадлежит, а так же, возможно, обновив свой «import:» или «export:» лист.

Таким образом мы сделали все, что необходимо для запуска своей AS с собственным блоком адресов.

Помним, что полное описание полей объекта можно получить выполнив в БД с ключем -v и именем объекта который нас интересует: пример.

Поля, отмеченные как [mandatory] являются обязательными для заполнения, должны обязательно присутствовать в заявке.

Поля, отмеченные как [single] могут присутствовать в заявке только в единственном экземпляре.

Поля, отмеченные как [multiple] могут присутствовать в нескольких экземплярах (например для указания нескольких телефонных номеров).

Поле «changed» должно содержать адрес электронной почты человека, который отправляет данную заявку (или вносит изменения) и дату внесения изменений в формате ГГГГММДД.

Поле «source» должно содержать значение «RIPE».

Поле «mnt-by» применяется для выбора способа авторизации дальнейших изменений в создаваемом объекте (см. объект «mntner«).

Удаление из БД делается точно так же как и создание. Единственное отличие, то что в конце добавляется поле «delete:» в котором вы и указываете причину удаления этого объекта.

Для удобства использования WebUpdates, дабы не вводить пароль от объекта mntner, можно использовать авторизацию до проведения необходимых изменений: смотреть

Пока это все что я хотел вам поведать, комментарии/замечания приветствуются.

Полезные ссылки:

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

З.Ы.Ы. Мы можем оказать вам содействие в получении статуса LIR, номера автономной системы и собственного блока адресов для Вашей организации на возмездной основе.

mntner object, as-set object, aut-num object, route object
inetnum object, person object, domain object, role object

Автор: Николаев Дмитрий (virus (at) subnets.ru)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 21, среднее: 4,57 из 5)
Loading...Loading...
Отправить на почту Отправить на почту