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

Архивные статьи в категории ‘Протоколы маршрутизации’

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

Все вы, у кого есть своя 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)
Загрузка...
Отправить на почту Отправить на почту

В продолжении статьи «Конфигурация OSPF на оборудовании Cisco Systems» посмотрим как в данной схеме можно выполнить редистрибуцию статических маршрутов, ну скажем на маршрутизаторе Б, в протокол OSPF.

Например на маршрутизаторе Б появился статический маршрут, ну скажем 192.168.0.0/24:

Switch> enable
Switch# configure terminal
Switch(config)# ip route 192.168.0.0 255.255.255.0 10.0.1.10

и мы хотим «вбросить» этот маршрут в OSPF.

С этой задачей нам поможет справится редистрибуция маршрутов из одного протокола в другой.

Приступим

1. Создадим access-list, по нему мы будем match`ить нужный нам маршрут(ы):

Switch(config)# ip access-list standard 10
Switch(config-std-nacl)# permit 192.168.0.0 0.255.255.255
Switch(config-std-nacl)# exit

2. Создадим маршрутную карту, в которой укажем access-list созданный в п.1:

Switch(config)# route-map redistr-static permit 100
Switch(config-route-map)# match ip address 10
Switch(config-route-map)# exit

3. Укажем OSPF, что мы хотим сделать редистрибуцию:

Switch(config)# router ospf 10
Switch(config-router)# redistribute static route-map redistr-static

4. Сохраним конфиг:

Switch(config-router)# exit
Switch(config)# exit
Switch# wri

Вот и все. Теперь все статические маршруты, попадающие под access-list 10 будут редистрибутированы в OSPF.

Не могу не подметить, что в команде redistribute, можно:
а) задать и метрику, с которой будет выполняться данная редистрибуция:

Switch(config-router)# redistribute static route-map redistr-static metric 15

б) задать tag, с которым будет распространяться маршрут (по нему, на других маршрутизаторах, можно определять откуда маршрут пришел):
Switch(config-router)# redistribute static route-map redistr-static metric 15 tag 1

Посмотрим, route-map и access-list на маршрутизаторе Б:
Switch# show route-map redistr-static

route-map redistr-static, permit, sequence 100
Match clauses:
ip address (access-lists): 10
Set clauses:
Policy routing matches: 0 packets, 0 bytes

Switch# show access-lists 10

Standard IP access list 10
    10 permit 192.168.0.0, wildcard bits 0.255.255.255 (2 matches)

На маршрутизаторе А вы должны видеть этот маршрут:
Switch# show ip route ospf | inc 192.168.0.0/24

O E2    192.168.0.0/24 [110/15] via 10.0.255.2, 1m, Vlan10

На маршрутизаторе В также:
Switch# show ip route ospf | inc 192.168.0.0/24

O E2    192.168.0.0/24 [110/15] via 10.0.255.9, 1m, Vlan100

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

З.Ы.Ы. Очепятки возможны. Если вы заметили неточность или у вас есть вопросы по данной схеме, то вы можете написать об этом на нашем форуме с соответствующем разделе.

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

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

OSPF (Open Shortest Path First) — протокол динамической маршрутизации, основанный на технологии отслеживания состояния канала (link-state technology) и использующий для нахождения кратчайшего пути Алгоритм Дейкстры (Dijkstra’s algorithm).

Последняя версия протокола представлена в RFC 2328. Протокол OSPF представляет собой протокол внутреннего шлюза (Interior Gateway Protocol — IGP), распространяет информацию о доступных маршрутах между маршрутизаторами одной автономной системы.

OSPF предлагает решение следующих задач:

  • Увеличение скорости сходимости;
  • Поддержка сетевых масок переменной длины (VLSM);
  • Достижимость сети;
  • Использование пропускной способности;
  • Метод выбора пути.

Теория

Терминология протокола OSPF

  • Объявление о состоянии канала (link-state advertisement, LSA) — объявление описывает все каналы маршрутизатора, все интерфейсы и состояние каналов.
  • Состояние канала (link state) — состояние канала между двумя маршрутизаторами; обновления происходят при помощи пакетов LSA.
  • Метрика (metric) — условный показатель «стоимости» пересылки данных по каналу;
  • Автономная система (autonomous system) — группа маршрутизаторов, обменивающаяся маршрутизирующей информацией с помощью одного протокола маршрутизации.
  • Зона (area) — совокупность сетей и маршрутизаторов, имеющих один и тот же идентификатор зоны.
  • Соседи (neighbours) — два маршрутизатора, имеющие интерфейсы в общей сети.
  • Состояние соседства (adjacency) — взаимосвязь между определенными соседними маршрутизаторами установленная с целью обмена информацией маршрутизации.
  • Hello-пакеты (hello packets) — используются для поддержания соседских отношений.
  • База данных соседей (neighbours database) — список всех соседей.
  • База данных состояния каналов (link state database, LSDB) — список всех записей о состоянии каналов. Встречается также термин топологическая база данных (topological database), употребляется как синоним базы данных состояния каналов.
  • Идентификатор маршрутизатора (router ID, RID) — уникальное 32-битовое число, которое уникально идентифицирует маршрутизатор в пределах одной автономной системы.
  • Выделенный маршрутизатор (designated router, DR) — управляет процессом рассылки LSA в сети. Каждый маршрутизатор сети устанавливает отношения соседства с DR. Информация об изменениях в сети отправляется DR, маршрутизатором обнаружившим это изменение, а DR отвечает за то, чтобы эта информация была отправлена остальным маршрутизаторам сети.Недостатком в схеме работы с DR маршрутизатором является то, что при выходе его из строя должен быть выбран новый DR. Новые отношения соседства должны быть сформированы и, пока базы данных маршрутизаторов не синхронизируются с базой данных нового DR, сеть будет недоступна для пересылки пакетов. Для устранения этого недостатка выбирается BDR.
  • Резервный выделенный маршрутизатор (backup designated router, BDR). Каждый маршрутизатор сети устанавливает отношения соседства не только с DR, но и BDR. DR и BDR также устанавливают отношения соседства и между собой. При выходе из строя DR, BDR становится DR и выполняет все его функции. Так как маршрутизаторы сети установили отношения соседства с BDR, то время недоступности сети минимизируется.

Краткое описание работы протокола

  1. Маршрутизаторы обмениваются hello-пакетами через все интерфейсы на которых активирован OSPF. Маршрутизаторы разделяющие общий канал передачи данных становятся соседями, когда они приходят к договоренности об определенных параметрах указанных в их hello-пакетах.
  2. На следующем этапе работы протокола маршрутизаторы будут пытаться перейти в состояние соседства со своими соседями. Переход в состояние соседства определяется типом маршрутизаторов обменивающихся hello-пакетами и типом сети по которой передаются hello-пакеты. OSPF определяет несколько типов сетей и несколько типов маршрутизаторов. Пара маршрутизаторов, находящихся в состоянии соседства синхронизирует между собой базу данных состояния каналов.
  3. Каждый маршрутизатор посылает объявление о состоянии канала маршрутизаторам с которыми он находится в состоянии соседства.
  4. Каждый маршрутизатор получивший объявление от соседа записывает информацию передаваемую в нем в базу данных состояния каналов маршрутизатора и рассылает копию объявления всем другим своим соседям.
  5. Рассылая объявления через зону, все маршрутизаторы строят идентичную базу данных состояния каналов маршрутизатора.
  6. Когда база данных построена, каждый маршрутизатор использует алгоритм кратчайший путь первым для вычисления графа без петель, который будет описывать кратчайший путь к каждому известному пункту назначения с собой в качестве корня. Этот граф это дерево кратчайшего пути.
  7. Каждый маршрутизатор строит таблицу маршрутизации из своего дерева кратчайшего пути.

В сетях со множественным доступом отношения соседства должны быть установлены между всеми маршрутизаторами. Это приводит к тому, что рассылается большое количество копий LSA. Если, к примеру, количество маршрутизаторов в сети со множественным доступом равно n, то будет установлено n(n-1)/2 отношений соседства. Каждый маршрутизатор будет рассылать n-1 LSA своим соседям, плюс одно LSA для сети, в результате сеть сгенерирует LSA.

Для предотвращения проблемы рассылки копий LSA в сетях со множественным доступом выбираются DR и BDR.

Маршрутизатор, выбранный DR или BDR в одной присоединенной к нему сети со множественным доступом, может не быть DR (BDR) в другой присоединенной сети. Роль DR (BDR) является свойством интерфейса, а не свойством всего маршрутизатора.

Таймеры протокола

  • HelloInterval — Интервал времени в секундах по истечению которого маршрутизатор отправляет следующий hello-пакет с интерфейса. Для широковещательных сетей и сетей точка-точка значение по умолчанию, как правило, 10 секунд. Для нешироковещательных сетей со множественным доступом значение по умолчанию 30 секунд.
  • RouterDeadInterval — Интервал времени в секундах по истечению которого сосед будет считаться «мертвым». Этот интервал должен быть кратным значению HelloInterval. Как правило, RouterDeadInterval равен 4 интервалам отправки hello-пакетов, то есть 40 секунд.
  • Wait Timer — Интервал времени в секундах по истечению которого маршрутизатор выберет DR в сети. Его значение равно значению интервала RouterDeadInterval.
  • RxmtInterval — Интервал времени в секундах по истечению которого маршрутизатор повторно отправит пакет на который не получил подтверждения о получении (например, Database Description пакет или Link State Request пакеты). Это интервал называется также Retransmit interval. Значение интервала 5 секунд.

Типы маршрутизаторов

Внутренний маршрутизатор (internal router) — маршрутизатор все интерфейсы которого принадлежат одной зоне. У таких маршрутизаторов только одна база данных состояния каналов.

Пограничный маршрутизатор (area border router, ABR) — соединяет одну или больше зон с магистральной зоной и выполняет функции шлюза для межзонального трафика. У пограничного маршрутизатора всегда хотя бы один интерфейс принадлежит магистральной зоне. Для каждой присоединенной зоны маршрутизатор поддерживает отдельную базу данных состояния каналов.

Магистральный маршрутизатор (backbone router) — маршрутизатор у которого всегда хотя бы один интерфейс принадлежит магистральной зоне. Определение похоже на пограничный маршрутизатор, однако магистральный маршрутизатор не всегда является пограничным. Внутренний маршрутизатор интерфейсы которого принадлежат нулевой зоне, также является магистральным.

Пограничный маршрутизатор автономной системы (AS boundary router, ASBR) — обменивается информацией с маршрутизаторами принадлежащими другим автономным системам. Пограничный маршрутизатор автономной системы может находиться в любом месте автономной системы и быть внутренним, пограничным или магистральным маршрутизатором.

Типы объявлений о состоянии канала (LSA)

Type 1 LSA — Router LSA — объявление о состоянии каналов маршрутизатора. Эти LSA распространяются всеми маршрутизаторами. В LSA содержится описание всех каналов маршрутизатора и стоимость (cost) каждого канала. Распространяются только в пределах одной зоны.

Type 2 LSA — Network LSA — объявление о состоянии каналов сети. Распространяется DR в сетях со множественным доступом. В LSA содержится описание всех маршрутизаторов присоединенных к сети, включая DR. Распространяются только в пределах одной зоны.

Type 3 LSA — Network Summary LSA — суммарное объявление о состоянии каналов сети. Объявление распространяется пограничными маршрутизаторами. Объявление описывает только маршруты к сетям вне зоны и не описывает маршруты внутри автономной системы. Пограничный маршрутизатор отправляет отдельное объявление для каждой известной ему сети.

Когда маршрутизатор получает Network Summary LSA от пограничного маршрутизатора он не запускает алгоритм вычисления кратчайшего пути. Маршрутизатор просто добавляет к стоимости маршрута указанного в LSA стоимость маршрута к пограничному маршрутизатору. Затем маршрут к сети через пограничный маршрутизатор помещается в таблицу маршрутизации.

Type 4 LSA — ASBR Summary LSA — суммарное объявление о состоянии каналов пограничного маршрутизатора автономной системы. Объявление распространяется пограничными маршрутизаторами. ASBR Summary LSA отличается от Network Summary LSA тем, что распространяется информация не о сети, а о пограничном маршрутизаторе автономной системы.

Type 5 LSA — AS External LSA — объявления о состоянии внешних каналов автономной системы. Объявление распространяется пограничным маршрутизатором автономной системы в пределах всей автономной системы. Объявление описывает маршруты внешние для автономной системы OSPF или маршруты по умолчанию (default route) внешние для автономной системы OSPF.

Type 7 LSA — AS External LSA for NSSA — объявления о состоянии внешних каналов автономной системы в NSSA зоне. Это объявление может передаваться только в NSSA зоне. На границе зоны пограничный маршрутизатор преобразует type 7 LSA в type 5 LSA.

Типы зон

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

Разделение на зоны позволяет:

  • Снизить нагрузку на ЦПУ маршрутизаторов за счет уменьшения количества перерасчетов по алгоритму SPF
  • Уменьшить размер таблиц маршрутизации
  • Уменьшить количество пакетов обновлений состояния канала

Каждой зоне присваивается идентификатор зоны (area ID). Идентификатор может быть указан в десятичном формате или в формате записи IP-адреса. Однако идентификаторы зон не являются IP-адресами и могут совпадать с любым назначенным IP-адресом.

Магистральная зона (backbone area)

Магистральная зона (известная также как нулевая зона (Area 0) или зона 0.0.0.0) формирует ядро сети OSPF. Все остальные зоны ДОЛЖНЫ быть соединены с ней, и межзональная маршрутизация происходит через маршрутизатор соединенный с магистральной зоной. Магистральная зона ответственна за распространение маршрутизирующей информации между немагистральными зонами. Магистральная зона должна быть смежной с другими зонами, но она не обязательно должна быть физически смежной; соединение с магистральной зоной может быть установлено и с помощью виртуальных каналов (virtual links).

Состояния OSPF соседа

Во время формирования соседских отношений OSPF роутеры (маршрутизаторы) проходят следущие состояния: Down, Attempt, Init, 2-Way, Exstart, Exchange, Loading, и Full.
Down state

Первое состояние OSPF соседа. В данном состоянии обмена Hello пакетами еще не производилось или соседские отношения развалились (состояние Full), по причине истечения RouterDeadInterval. Hello-пакеты в данном состоянии принимаются.

Attempt state

Это состояние проходят вручную прописанные в конфигурацию роутера OSPF работающего в NBMA среде (Nonbroadcast Multiple Access Network (NBMA) — среда не поддерживающая распространение multicast и broadcast трафика). В этом состоянии роутер посылает юникаст (unicast) hello-пакеты со своего unicast адреса на unicast адрес соседа.

Init state

Состояние инициализации, когда роутер получил hello пакет от соседа на один из интерфейсов OSPF, но RID получателя ещё небыл включен (вписан) в hello-пакет. Роутер вставляет RID соседа, от которого был получен hello-пакет, в свой hello-пакет как подтверждение того, что он был получен.

2Way state

В данном состоянии между роутерами установлен двунаправленный обмен, т.к. при разборе пришедшего hello-пакета содержится RID этого роутера, т.е. оба роутера получили hello-пакеты друг от друга. Именно в конце установки этого состояния в broadcast среде проиходят выборы DR и BDR если они ещё отсутствуют в Area в которой находятся интерфейсы роутера на которые были получены hello-пакеты.

В NBMA среде выборов DR и BDR не производится.

Exstart state

После выборов DR и BDR, между роутерами и DR, BDR начинается процесс обмена пакетами DBD (Database Descriptor) c информацией о состоянии каналов. В этом состоянии, роутеры и их DR и BDR устанавливают отношения master-slave . Роутер с самым большим Router ID (RID) становиться master и начинает обмен.

Exchange state

В этом состояни, OSPF роутеры обмениваются пакетами дескрипторами базы данных (DBD). Дескрипторы базы данных содержат только заголовки LSA, которые описывают содержимое всей базы данных о состоянии каналов. Каждый DBD пакет имеет номер, который увеличивается только master роутером и обязатесльно подтверждается slave`вом. Роутеры посылают link-state request пакеты и link-state update пакеты, они содержат всю LSA. Содержимое полученного DPD сравнивается с информацией содержащейся в link-state database роутера, идет поиск, имеются ли новые сведения о состоянии каналов доступных соседу.

Loading state

Происходит непосредственно обмен информацией о состоянии канала. Основываясь на информации полученной через DBD, роутеры посылают link-state request пакеты о состоянии канала. Затем сосед предоставляет запрошенную link-state информацию в link-state update пакетах. Во время adjacency, если роутер принял устаревшую или отсутствующую LSA, он запрашивает эту LSA, посылая link-state request пакет. Все link-state update пакеты нуждаются в обязательном подтвеждении (acknowledgment).

Full state

В этом состоянии соседские отношения полностью установлены. Роутеры обменялись LSA и база данных, на роутерах, полностью синхронизирована. Состояние Full является нормальным состоянием для OSPF роутера.

Роутер может «застрять» в каком-то из состояний, это указывает на проблему в формировании связности (adjacency). Исключением является состояние 2Way, которое является обычным для соседей в broadcast среде. Состояние Full устанавливается только с DR и BDR. С остальными соседями в этой среде будет установлено состояние 2WAY/DROTHER.

В broadcast среде, все OSPF роутеры общаются через multicast адрес 224.0.0.5, но DR и BDR, для общения между собой, используют multicast адрес 224.0.0.6. Благодаря тому, что в broadcast среде работает multicast, определение и нахождение OSPF соседей происходит автоматически.

Формат пакетов

О форматах пакетов OSPF подробно написано тут.

В завершении

В статье используются материалы сайтов:

Полезная литература: Структура и реализация сетей на основе протокола OSPF.

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

Итак, вы в качестве пограничного маршрутизатора своей AS выбрали маршрутизатор Juniper.

Поздравляю вас ! Вы сделали отличный выбор ! 😉

В этой статье я постараюсь рассказать как настроить протокол BGP на оборудовании этого производителя.

Это не how-to на все случаи в жизни, а пример, с которого можно хоть как-то начать постигать замечательное железо от Juniper.

В качестве примера буду использовать:

Наша автономная система: AS100

Наш префикс: 1.1.0.0/20

Схема подключения:

Два апстрима: AS200 (2.2.2.1/30) и AS300 (3.3.3.1/30)

И один прямой пиринг с AS400 (4.4.4.1/30)

Схема подключения

Схема подключения

Будем подразумевать, что соответствующие IP интерфейсы на маршрутизаторе вы уже настроили. Пример настройки интерфейсов можно посмотреть в этой статье и сделать по аналогии.

Настройка протокола BGP начинается с секции protocols.

Войдем в режим конфигурации:

root@juniper> configure

перейдем в раздел protocols bgp

[edit]
root@juniper#
edit protocols bgp

Начнем с того, что укажем номер своей автономной системы:

[edit protocols bgp]
root@juniper# set
local-as 100

Зададим логирование изменений состояния «соседей» (peer):

[edit protocols bgp]
root@juniper#
set log-updown

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

[edit protocols bgp]
root@juniper#
set advertise-inactive

Зададим route flap damping (так называемые «хлопающие» маршруты):

[edit protocols bgp]
root@juniper#
set damping

Укажем лог файл:

[edit protocols bgp]
root@juniper#
set traceoptions file bgp.log size 1m files 50

Теперь можно приступить к настройке соседей (peer). Как мы условились выше у нас два апстрима. Для удобства создадим группу upstreams:

[edit protocols bgp]
root@juniper# set group upstreams

перейдем в конфигурировние созданной группы:

[edit protocols bgp]
root@juniper# edit group upstreams

Укажем некоторые параметры для всей группы, например тип:

[edit protocols bgp group upstreams]
root@juniper# set type external

И несколько других параметров:

[edit protocols bgp group upstreams]
root@juniper# set description «Upstreams peers»

[edit protocols bgp group upstreams]
root@juniper# no-advertise-peer-as

Для Load-balancing включим multiple-as

[edit protocols bgp group upstreams]
root@juniper# set multipath multiple-as

Создадим первого соседа:

[edit protocols bgp group upstreams]
root@juniper# set neighbor
2.2.2.1 description Prov-1

Зададим его автомномную систему:

[edit protocols bgp group upstreams]
root@juniper# set neighbor
2.2.2.1 peer-as 200

Зададим маршрутные карты, которые будут отрабатываться при импорте маршрутов от этого соседа. У Juniper можно задавать «конвеер» маршрутных карт:

[edit protocols bgp group upstreams]
root@juniper# set neighbor
2.2.2.1 import [ bogus-reject bogus-ases default-route-reject Prov-1-in ]

Зададим маршрутные карты, которые будут отрабатываться при экспорте маршрутов от нас к соседу:

[edit protocols bgp group upstreams]
root@juniper# set neighbor
2.2.2.1 export Prov-1-out

Тоже самое сделаем и по второму апстриму:

[edit protocols bgp group upstreams]
root@juniper# set neighbor
3.3.3.1 description Prov-2

[edit protocols bgp group upstreams]
root@juniper# set neighbor
3.3.3.1 peer-as 300

[edit protocols bgp group upstreams]
root@juniper# set neighbor
3.3.3.1 import [ bogus-reject bogus-ases default-route-reject Prov-2-in ]

[edit protocols bgp group upstreams]
root@juniper# set neighbor
3.3.3.1 export Prov-2-out

Если вы собираетесь оглашать всем соседям этой группы одно и то же, то можно поступить немного проще, задав export сразу для всей группы (но это будет неудобно, т.к. в процессе использования BGP линков вы поймете, что не всегда всем апстримам нужно слать одно и то же):

[edit protocols bgp group upstreams]
root@juniper# set
export upstreams-out

С апстримами разобрались, теперь создадим группу для прямого пиринга:

[edit protocols bgp group upstreams]
root@juniper# up

[edit protocols bgp]
root@juniper# set group peers

[edit protocols bgp]
root@juniper# edit group peers

[edit protocols bgp group peers]
root@juniper# set type external

[edit protocols bgp group peers]
root@juniper# set description «Our peers»

[edit protocols bgp group peers]
root@juniper# no-advertise-peer-as

Создадим запись о прямом пиринге с AS400:

[edit protocols bgp group peers]
root@juniper# set neighbor
4.4.4.1 description Peer-1

[edit protocols bgp group peers]
root@juniper# set neighbor
4.4.4.1 peer-as 400

Т.к. это прямой пиринг, то и принимать от этого соседа мы будем только те маршруты которые относятся к его AS, а не full-view, поэтому в данном случае мы не делаем «конвеер».

[edit protocols bgp group peers]
root@juniper# set neighbor
4.4.4.1 import Peer-1-in

[edit protocols bgp group peers]
root@juniper# set neighbor
4.4.4.1 export Peer-1-out

Так мы выполнили первую часть. Можете взглянуть на свои труды:

[edit protocols bgp group peers]
root@juniper# up

[edit protocols bgp]
root@juniper# show group upstreams

[edit protocols bgp]
root@juniper# show group peers

Для меня оборудование Juniper сильно выделяется на фоне оборудования Cisco Systems тем, что измененная конфигурация вступает в силу только в одном случае, когда вы даете команду commit. До этого момента на маршрутизаторе действует предыдущая «закомиченная» (commited) конфигурация. Перед тем как применять/комитить конфигурацию, можно проверить её на ошибки:

[edit protocols bgp group upstreams]
root@juniper# commit check

Если вы сделали commit check на данном этапе, то Juniper обязательно ругнется на отсутвие маршрутных карт, т.к. мы их прописали у соседей, но ещё не создавали. Вот именно это, кстати не единственное, что меня очень радует в этом оборудовании, т.к. у Cisco Systems можно указать маршрутную карту на соседа, но забыть её создать и Cisco ничего не скажет по этому поводу, а Juniper не даст вам «закомитить» (выполнить команду commit) пока в конфигурации есть ошибки, в данном случае отсутствие маршрутных карт.

Теперь нужно заняться своими префиксами и маршрутными картами.

Перейдем в другую секцию конфигурации и разберемся с нашими маршрутами:

[edit protocols bgp]
root@juniper# top

[edit]
root@juniper# edit routing-options

Укажем свой router-id, обычно это IP адрес из вашего блока который есть на этом маршрутизаторе:

[edit routing-options]
root@juniper# set router-id 1.1.1.1

Снова укажем номер своей AS:

[edit routing-options]
root@juniper# set autonomous-system 100

Тут же зададим название маршрутной карты с политикой для load-balance:

[edit routing-options]
root@juniper# set forwarding-table export per-flow-load-balancing

Создадим статические маршруты для нашего блока /20, (т.к. вы должны уже знать то, что протокол BGP не будет оглашать те маршруты, для которых он не знает next-hop адреса) но разбив его на две части. Сделаем это для того, что бы каким-либо другим соседям, например при установке прямого пиринга с AS400 которая не является вашим апстримом, чтобы оглашать ей маршуты с большей маской и соответвенно они будут иметь больший приоритет при выборе маршрута из данной AS к вам:

[edit routing-options]
root@juniper# set static route
1.1.0.0/21 next-hop 1.1.1.2 retain readvertise

[edit routing-options]
root@juniper# set static route
1.1.8.0/21 next-hop 1.1.1.2 retain readvertise

IP-адрес 1.1.1.2 это следующий маршрутизатор внутри нашей AS100.

Т.к. это пограничный маршрутизатор, а значит «серые» сети не должны выходить за его пределы, выполним следущее (discard):

[edit routing-options]
root@juniper# set route 10.0.0.0/8 discard

[edit routing-options]
root@juniper# set route 172.16.0.0/12 discard

[edit routing-options]
root@juniper# set route 192.168.0.0/16 discard

Не будем «насиловать» лишними маршрутами своих апстримов и будем им оглашать весь блок /20 целиком. Для этого сделаем агрегирование:

[edit routing-options]
root@juniper# set aggregate route 1.1.0.0/20 discard

Посмотрим что получилось в этой секции:

[edit routing-options]
root@juniper# show

Настало время создать маршрутные карты. Начнем с per-flow-load-balancing.

Перейдем в другую секцию:

[edit routing-options]
root@juniper# top

[edit]
root@juniper# edit policy-options

Создадим для per-flow-load-balancing:

[edit policy-options]
root@juniper# set policy-statement per-flow-load-balancing term balance then load-balance per-packet

Приступим к дефолтным маршрутным картам для соседей.

Для начала bogus-reject:

[edit policy-options]
root@juniper# set
policy-statement bogus-reject from route-filter 127.0.0.0/8 orlonger

[edit policy-options]
root@juniper# set
policy-statement bogus-reject from route-filter 10.0.0.0/8 orlonger

[edit policy-options]
root@juniper# set
policy-statement bogus-reject from route-filter 172.16.0.0/12 orlonger

[edit policy-options]
root@juniper# set
policy-statement bogus-reject from route-filter 192.168.0.0/16 orlonger

[edit policy-options]
root@juniper# set
policy-statement bogus-reject from route-filter 169.254.0.0/16 orlonger

[edit policy-options]
root@juniper# set
policy-statement bogus-reject from route-filter 224.0.0.0/4 orlonger

[edit policy-options]
root@juniper# set
policy-statement bogus-reject from route-filter 240.0.0.0/4 orlonger

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

[edit policy-options]
root@juniper# set
policy-statement bogus-reject then reject

Создадим default-route-reject для запрета приема default gateway по протоколу BGP:

[edit policy-options]
root@juniper# set
policy-statement default-route-reject from route-filter 0.0.0.0/0 exact

[edit policy-options]
root@juniper# set
policy-statement default-route-reject then reject

Создадим bogus-ases для запрета приема «серых» (private) номеров AS:

[edit policy-options]
root@juniper# set
policy-statement bogus-ases from as-path grey-as

[edit policy-options]
root@juniper# set
policy-statement bogus-ases then reject

[edit policy-options]
root@juniper# set
policy-statement as-path grey-as 64512-65535

Пришло время для карт для соседей. В маршрутных картах на in (input) вы можете «играться» с теми или иными маршрутами приходящими от соседей. Фильтровать что-то, поднимать local-prefence и т.п. Для примера покажу как поднять local-prefence на маршрутах, для которых ваш апстрим является origin (т.е. те маршруты, которые принадлежат его AS).

Итак Prov-1-in:

[edit policy-options]
root@juniper# set
policy-statement Prov-1-in term own-as from as-path prov-1-as

[edit policy-options]
root@juniper# set
policy-statement Prov-1-in term own-as then local-preference 200

[edit policy-options]
root@juniper# set
policy-statement Prov-1-in term own-as then accept

Теперь создадим as-path:

[edit policy-options]
root@juniper# set as-path
prov-1-as «.*200»

Т.к. orign AS для маршрута всегда находится в конце as-path, то я и задал регулярное выражение которое ищет AS200 в конце as-path. Подробнее о регулярных выражениях читайте в технической документации по вашей версии JUNOS. Вы можете использовать не только as-path, но и префиксы которые принадлежат данному апстриму. Это на ваш выбор. Я выбрал as-path потому, что бы каждый раз не лазать и не изменять конфиг когда у этого апстрима появится новый блок IP-адресов.

Теперь зададим последний этап обработки приходящих от этого апстрима маршутов и действий с ними. Т.к. у нас full-view, то логично, что мы разрешим все остальное:

[edit policy-options]
root@juniper# set
policy-statement Prov-1-in term final-accept then accept

Тут же вы можете выставить default local-preference для этого апстрима:

[edit policy-options]
root@juniper# set
policy-statement Prov-1-in term final-accept then local-preference 100

Проделайте тоже самое и для Prov-2-in подставив туда его значения создав policy-statement Prov-2-in и as-path с AS300.

Для примера для нашего прямого пира AS400 мы создадим маршрутку с его префиксами, а не с as-path:

[edit policy-options]
root@juniper# set
policy-statement Peer-1-in term own-prefix from prefix-list-filter peer-1-prefix exact

[edit policy-options]
root@juniper# set
policy-statement Peer-1-in term own-prefix then accept

Поднимем local-preference для этих маршрутов выше, чем все остальное:

[edit policy-options]
root@juniper# set
policy-statement Peer-1-in term own-prefix then local-preference 210

Теперь запретим все остальное (т.к. как я уже говорил это прямой пир, а не апстрим, а раз так то принимаем только те префиксы, которые ему принадлежат):

[edit policy-options]
root@juniper# set
policy-statement Peer-1-in term final-reject then reject

Ну и осталось создать peer-1-prefix который мы прописали выше и указать в нем префиксы, которые принадлежат AS400, допустим это будут префиксы:

  • 195.128.0.0/16
  • 77.87.224.0/21

[edit policy-options]
root@juniper# set prefix-list
peer-1-prefix 195.128.0.0/16

[edit policy-options]
root@juniper# set prefix-list
peer-1-prefix 77.87.224.0/21

Итак с приемом маршрутов разобрались, приступим к оглашению наших. Эта задача состоит из двух частей:

  • оглашение агрегированного маршрута для апстримов
  • оглашение разделенного блока /20 для прямого пира

При прописывании всех наших соседей мы использовали разные маршрутные карты для того, что бы у нас была возможность управлять анонсами для каждого соседа по разному. Это вам пригодится для управления входящим в вашу AS трафиком, например prepend`ом.

Начнем с AS200 (первый апстрим) и как мы условились апстримам мы оглашаем агрегированный маршрут:

[edit policy-options]
root@juniper# set
policy-statement Prov-1-out term my-prefix from protocol aggregate

[edit policy-options]
root@juniper# set
policy-statement Prov-1-out term my-prefix from policy our-CIDR-blocks-aggregated

[edit policy-options]
root@juniper# set
policy-statement Prov-1-out term my-prefix then accept

Создадим сам фильтр policy our-CIDR-blocks-aggregated:

[edit policy-options]
root@juniper# set
policy-statement our-CIDR-blocks-aggregated term AS100-prefix from route-filter 1.1.0.0/20 exact

[edit policy-options]
root@juniper# set
policy-statement our-CIDR-blocks-aggregated term AS100-prefix then accept

Т.к. на данном этапе мы всем апстримам оглашаем одно и тоже, то создайте Prov-2-out сами.

Теперь нужно сделать out для нашего прямого пира и оглашать мы ему будем две сети /21:

[edit policy-options]
root@juniper# set
policy-statement Peer-1-out term AS100-prefix from protocol static

[edit policy-options]
root@juniper# set
policy-statement Peer-1-out term AS100-prefix from policy our-CIDR-blocks

[edit policy-options]
root@juniper# set
policy-statement Peer-1-out term AS100-prefix then accept

[edit policy-options]
root@juniper# set
policy-statement Peer-1-out term final-reject then reject

[edit policy-options]
root@juniper# set
policy-statement our-CIDR-blocks term AS100-prefixes from route-filter 1.1.0.0/21 exact

[edit policy-options]
root@juniper# set
policy-statement our-CIDR-blocks term AS100-prefixes from route-filter 1.1.8.0/21 exact

[edit policy-options]
root@juniper# set
policy-statement our-CIDR-blocks term AS100-prefixes then accept

Ну вот вроде на первый взляд и все. Проверим все ли в порядке:

[edit policy-options]
root@juniper# commit check

Если в ответ вы получили сообщение:

configuration check succeeds

значит ошибок в конфигурации нет и вы можете применять её на маршрутизаторе. Сделаем это и добавим комментарий к этому конфигу:

[edit policy-options]
root@juniper# commit comment «My first configuration»

Juniper может хранить до 50-ти «закомиченных» конфигураций и вы всегда можете откатываться к любой их них, поэтому я рекомендую всегда добавлять комментарий к конфигу, чтобы потом различать их 🙂

Посмотреть состояние всех соседей можно командой:

[edit policy-options]
root@juniper# run show bgp summary

Т.к. мы все ещё находимся в режиме конфигурирования нам приходится добавлять ключевое слово run чтобы команда show отработала не на конфигурации.

Если мы выйдем из режима конфигурирования:

[edit policy-options]
root@juniper# exit

то тут слово run добавлять уже не нужно:

root@juniper> show bgp summary

Другие команды для просмотра состояний соседей, пришедших/отправленных им маршрутах и т.п. я рассмотрю в другой статье.

Мануал, по всем командам, вы можете прочитать в технической документации по вашей версии Junos на сайте производителя: www.juniper.net

Рекомендую полистать книгу:

JUNOS Cookbook
By Aviva Garrett
………………………………………..
Publisher: O’Reilly
Pub Date: April 2006
Print ISBN-10: 0-596-10014-0
Print ISBN-13: 978-0-59-610014-8
Pages: 682

Заранее прошу прощения за оЧепЯтки и неточности. По мере нахождения багов и замечаний статья будет изменяться.

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

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

Очень часто у новичков возникает вопрос:

«Что нужно настроить на Cisco Catalyst с нуля?»

или встречается запрос в google:

«Скачать дефолтовый конфиг для Cisco Catalyst»

или

«catalyst 2960 2950 3560 ip адрес по умолчанию»

или

«как настроить cisco catalyst «

Попробую немного помочь этим людям 🙂

  1. Дефолтовых конфигов не бывает, т.к. у каждого своя сеть и свои «правила»
  2. Нету у Cisco IP-адреса по умолчанию (это же не Dlink), все настраивается ручками и сначала через консоль.

Итак, попробуем разобраться в том, что желательно настроить на нулевом Cisco Catalyst ?

Например, часто встречающиеся:

  • Cisco Catalyst 2950
  • Cisco Catalyst 2960
  • Cisco Catalyst 3550
  • Cisco Catalyst 3560
  • Cisco Catalyst 3560G

Я использовал Cisco Catalyst 3560G

0. Подключаемся к cisco по консольному кабелю через com порт:

FreeBSD через com порт:

cu -l /dev/cuad0

FreeBSD через переходник USB->Com:

  • kldload uplcom.ko
  • kldstat | grep uplcom (убедиться что подгрузился)
  • подключить переходник к USB порту
  • cu -l /dev/cuaU0

в Windows можно использовать Hiper Terminal для подключения к com порту

1. Зададим пароль на enable режим

Switch> enable

Switch# configure terminal

Switch(config)# enable password my-secret-password

2. Установим пароль для входа по telnet

Switch(config)# line vty 0 15

Switch(config-line)#password my-telnet-password

3. Сразу разрешим вход по telnet

Switch(config-line)# login

Switch(config)# exit

4. Зашифруем пароли, чтобы по sh run они не показывались в открытом виде

Switch(config)# service password-encryption

5. Зададим имя девайсу, например будет c3560G

Switch(config)# hostname c3560G

6. повесим / присвоим IP-адрес нашему девайсу

c3560G(config)# interface vlan 1

c3560G(config-if)# ip address 192.168.1.2 255.255.255.0

c3560G(config-if)# exit

7. Если вы ошибетесь при наборе чего либо в консоле, то циска начнет пытаться это отрезолвить, чем заставляет вас ждать, выключим эту фичу

c3560G(config)# no ip domain-lookup

8. Зададим имя домена

c3560G(config)# ip domain-name my-domain.ru

9. Зададим IP-адрес DNS сервера

c3560G(config)# ip name-server 192.168.1.15

10. Зададим время

если у вас есть доступный NTP сервер

c3560G(config)# ntp server 192.168.1.1 version 2 source vlan 1

c3560G(config)# ntp clock-period 36029056

c3560G(config)# ntp max-associations 1

где 192.168.1.1 — это IP-адрес NTP сервера

а используя «добавку» source vlan вы можете четко задать номер vlan с IP которого будет отправляться NTP запрос

если нет NTP сервера, то можно задать время вручную, но для этого придется выйти из режима конфигурирования

c3560G(config)# exit

c3560G# clock set 20:00:50 23 Aug 2008

11. Зададим переход с зимнего на летнее время и наоборот

c3560G# configure terminal

c3560G(config)# clock timezone MSK 3

c3560G(config)# clock summer-time MSD recurring last Sun Mar 2:00 last Sun Oct 2:00

12. Сделаем так, чтобы по команде show logging отображалось нормальное время, а не кол-во дней и т.п.

c3560G(config)# service timestamps log datetime localtime

13. Зададим дефолтовые настройки сразу всем портам на девайсе (у меня catalyst 24 порта + 4 SFP)

c3560G(config)# interface range gi 0/1 — 28

c3560G(config-if-range)# description not_used

c3560G(config-if-range)# shutdown

c3560G(config-if-range)# no cdp enable

c3560G(config-if-range)# switchport nonegotiate

c3560G(config-if-range)# switchport mode access

c3560G(config-if-range)# exit

Рекомендую: все неиспользуемые порты держать выключенными, а ещё лучше создать влан (например 999) и все выключенные порты переместить в него:

c3560G(config)# vlan 999

c3560G(config-vlan)# name unused_ports

c3560G(config-vlan)# shutdown

c3560G(config-vlan)# exit

c3560G(config)# interface range gi 0/1 — 28

c3560G(config-if-range)# description not_used

c3560G(config-if-range)# shutdown

c3560G(config-if-range)# no cdp enable

c3560G(config-if-range)# switchport nonegotiate

c3560G(config-if-range)# switchport access vlan 999

c3560G(config-if-range)# switchport mode access

c3560G(config-if-range)# exit

14. Выключим web-интерфейс, командная строка рулит 😉

c3560G(config)# no ip http server

15. Зададим gateway по умолчанию (допустим это будет 192.168.1.1, т.к. мы присвоили девайсу IP 192.168.1.2/255.255.255.0)

c3560G(config)# ip default-gateway 192.168.1.1

16. Если этот свич будет моддерживать маршрутизацию (будет router`ом), то включим функцию маршрутизации (если это позволяет сам девайс и его прошивка)

3560G прекрасно справляется с функцией маршрутизации

c3560G(config)# ip routing

c3560G(config)# ip classless

c3560G(config)# ip subnet-zero

17. Если вы выолнили пункт 16-ть, то снова необходимо задать gateway по умолчанию, но уже другой командой

c3560G(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.1

18. Настроим access-list для доступа к свичу только с определенных IP-адресов

c3560G(config)# ip access-list standard TELNET

c3560G(config-std-nacl)# permit 192.168.1.1

c3560G(config-std-nacl)# permit 192.168.1.15

c3560G(config-std-nacl)# exit

19. Применим этот access-list

c3560G(config)# line vty 0 15

c3560G(config-line)# access-class TELNET in

20. Зададим timeout неактивности telnet сессии, по истечении указанного времени, если вы в консольке ничего не вводили, то telnet соединение будет автоматически закрываться

c3560G(config-line)# exec-timeout 5 0

c3560G(config-line)# exit

21. Включим SNMP, но только read only (RO) и доступность только с хоста 192.168.1.1

c3560G(config)# snmp-server community RO-MY-COMPANY-NAME RO

c3560G(config)# snmp-server trap-source Vlan1

c3560G(config)# snmp-server source-interface informs Vlan1

c3560G(config)# snmp-server location SWITCH-LOCATION

c3560G(config)# snmp-server contact my-email@my-domain.ru

c3560G(config)# snmp-server host 192.168.1.1 RO-MY-COMPANY-NAME

c3560G(config)# exit

22. Ну и наконец сохраним свои труды

c3560G# copy running-config startup-config

или можно проще и короче 🙂

c3560G# wri

Море документации по catalyst`ам, и не только по ним, вы можете найти, ессно, на сайте производителя: www.cisco.com

23. Если хочется включить на девайсе ssh, чтобы подключаться к cisco по ssh (если это позволяет установленный IOS), то выполним следущее:

а) Обязательно указываем имя домена (необходимо для генерации ключа) см. пункт 8.

б) cisco(config)# crypto key generate rsa

в) cisco(config)# line vty 0 15

г) cisco(config)# transport preferred none

д) cisco(config)# transport input ssh

е) cisco(config)#transport output ssh

Подробнее по настройке ssh: Configuring Secure Shell on Routers and Switches Running Cisco IOS

24. Устранение критической уязвимости в коммутаторах Cisco, которой подвержен Smart Install (работает по TCP порт 4786).
cisco(config)#no vstack
Затем убедиться что сиё зло отключилось, команда:
cisco#show vstack config

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

Автор: Николаев Дмитрий (virus (at) subnets.ru)
Configuring Secure Shell on Routers and Switches Running Cisco IOS
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 18, среднее: 4,83 из 5)
Загрузка...
Отправить на почту Отправить на почту