По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет! Мы уже рассказывали про операционные системы для устройств Cisco – IOS, IOS-XE, CatOS. В этой статье мы рассмотрим NX-OS и IOS-XR, а также сравним их с традиционной IOS.
На верхнем уровне их можно соотнести так:
Cisco IOS: используется в borderless сетях (то есть это сети, которые позволяют кому угодно, где угодно и с любого устройства подключаться к корпоративной сети). Например, маршрутизатор ISR2 Cisco 3900 Series использует Cisco IOS;
Cisco NX-OS: используется в коммутаторах Cisco Nexus, расположенных в центрах обработки данных. Например, коммутатор Cisco Nexus 7000 работает под управлением Cisco NX-OS;
Cisco IOS-XR: используется на маршрутизаторах провайдеров связи. Например, маршрутизатор Cisco XR 12000 Series использует Cisco IOS-XR.
Cisco IOS
Хотя имя «IOS» появилось позже, операционная система относится к середине 1980-х годов. Cisco IOS была разработана с использованием языка программирования C и имела несколько ограничений, указывающих на то, когда она была разработана. Например, он не поддерживал симметричную многопроцессорную обработку. В результате одна инструкция должна была быть завершена до того, как начнется выполнение другой. Еще одним огромным архитектурным ограничением было использование общего пространства памяти, в результате которого один неправильный процесс мог нанести ущерб другим процессам маршрутизатора.
У некоторых платформ марщрутизаторов были обходные пути. Например модульный маршрутизатор Cisco 7513 – он может быть оснащен модулем универсального интерфейса (VIP), который позволяет отдельным линейным картам запускать собственные экземпляры Cisco IOS. Это обеспечило некоторый уровень балансировки нагрузки и избыточности.
Еще одна версия Cisco IOS - это IOS-XE, которая запускает Cisco IOS в Linux. В качестве примера можно найти Cisco IOS-XE, работающую на маршрутизаторе Cisco ASR 1000 Series. Благодаря набору функций Linux, Cisco IOS-XE добавляет поддержку симметричной многопроцессорности и отдельных пространств памяти. Однако, помимо своих Linux-подходов, Cisco IOS-XE в основном похожа на традиционную Cisco IOS.
Cisco NX-OS
Первоначально имевшая название SAN-OS (где акроним SAN обозначался как Storage Area Network), NX-OS предлагает некоторые обширные архитектурные улучшения по сравнению с традиционными Cisco IOS. Хотя первоначально это была 32-разрядная операционная система, с тех пор она превратилась в 64-разрядную ОС. В отличие от Cisco IOS, NX-OS не использует одно пространство памяти и поддерживает симметричную многопроцессорность. Она также имеет превентивную многозадачность, что позволяет высокоприоритетному процессу получить время процессора перед процессом с более низким приоритетом.
NX-OS построена на ядре Linux, и поддерживает язык Python для создания сценариев на коммутаторах Cisco Nexus. Кроме того, она имеет несколько функций высокой доступности (high availability), и не загружает сразу все ее функции. Вместо этого можно указать, какие функции вы хотите активировать. Устранение ненужных функций освобождает память и процессор для тех функций, которые вам нужны. Однако когда дело доходит до конфигурации, существует много сходства между NX-OS и Cisco IOS.
Cisco IOS-XR
Первоначально разработанная для 64-разрядной работы, IOS-XR предлагает множество улучшений, обнаруженных в NX-OS (например, симметричная многопроцессорность, отдельные пространства памяти и активация только тех сервисов, которые необходимы). Однако, хотя NX-OS построена на ядре Linux, IOS-XR построен на микроядре QNX Neutrino Microkernel.
Функция IOS-XR, которой нет в NX-OS, - это возможность иметь один экземпляр операционной системы, управляющей несколькими шасси. Кроме того, поскольку IOS-XR ориентирована на среды провайдеров, она предлагает поддержку таких интерфейсов, как DWDM и Packet over SONET.
В то время как конфигурация IOS-XR имеет некоторое сходство с традиционной IOS, различия намного заметнее, чем различия в NX-OS. Например, когда вы закончили вводить команды конфигурации, вам необходимо зафиксировать свои изменения, чтобы они вступили в силу и до выхода из режима конфигурации.
Примеры конфигурации
Чтобы проиллюстрировать некоторые основные конфигурации этих трех операционных систем, рассмотрим следующие примеры.
Эти команды были предоставлены маршрутизатору Cisco IOS, коммутатору NX-OS и экземплярам маршрутизатора IOS-XR, работающим в Cisco VIRL. В каждом из следующих примеров показана текущая версия маршрутизатора или коммутатора. Затем мы входим в глобальный режим конфигурации и изменяем имя хоста маршрутизатора или коммутатора, а затем создаем интерфейс Loopback 0, назначая IP-адрес этому интерфейсу, выходя из режима привилегий и выдавая команду show ip interface brief.
При назначении IP-адресов интерфейсам Loopback на устройствах следует заметить, что Cisco IOS требует, чтобы маска подсети была введена в десятичной системе с точками, в то время как NX-OS и IOS-XR поддерживают ввод маски подсети с использованием слеша.
Также нужно обратить внимание, что перед выходом из режима конфигурации необходимо выполнить команду commit на IOS-XR. Кроме того, только когда мы применяем эту команду, применяется наша обновленная конфигурация имени хоста.
IOS:
Router>show version
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.1(4)M4, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Thurs 5-Jan-12 15:41 by pt_team
ROM: System Bootstrap, Version 15.1(4)M4, RELEASE SOFTWARE (fc1)
cisco2911 uptime is 40 seconds
System returned to ROM by power-on
System image file is "flash0:c2900-universalk9-mz.SPA.151-1.M4.bin"
Last reload type: Normal Reload
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to
export@cisco.com.
Cisco CISCO2911/K9 (revision 1.0) with 491520K/32768K bytes of memory.
Processor board ID FTX152400KS
3 Gigabit Ethernet interfaces
DRAM configuration is 64 bits wide with parity disabled.
255K bytes of non-volatile configuration memory.
249856K bytes of ATA System CompactFlash 0 (Read/Write)
License Info:
License UDI:
-------------------------------------------------
Device# PID SN
-------------------------------------------------
*0 CISCO2911/K9 FTX15246R1P
Technology Package License Information for Module:'c2900'
----------------------------------------------------------------
Technology Technology-package Technology-package
Current Type Next reboot
-----------------------------------------------------------------
ipbase ipbasek9 Permanent ipbasek9
security None None None
uc None None None
data None None None
Configuration register is 0x2102
Router>en
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#hostname IOS-ROUTER
IOS-ROUTER(config)#interface loopback0
IOS-ROUTER(config-if)#
%LINK-5-CHANGED: Interface Loopback0, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
IOS-ROUTER(config-if)#ip address 10.1.1.1 255.255.255.255
IOS-ROUTER(config-if)#end
IOS-ROUTER#
%SYS-5-CONFIG_I: Configured from console by console
IOS-ROUTER#show ip int brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 unassigned YES unset administratively down down
GigabitEthernet0/1 unassigned YES unset administratively down down
GigabitEthernet0/2 unassigned YES unset administratively down down
Loopback0 10.1.1.1 YES manual up up
Vlan1 unassigned YES unset administratively down down
IOS-ROUTER#
NX-OS:
switch#show version
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2010, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
Software
BIOS: version 1.3.0
loader: version N/A
kickstart: version 5.0(2)N2(1) [build 5.0(2)N2(1)]
system: version 5.0(2)N2(1) [build 5.0(2)N2(1)]
power-seq: version v1.2
BIOS compile time: 09/08/09
kickstart image file is: bootflash:/sanity-kickstart
kickstart compile time: 12/6/2010 7:00:00 [12/06/2010 07:35:14]
system image file is: bootflash:/sanity-system
system compile time: 12/6/2010 7:00:00 [12/06/2010 08:56:45]
Hardware
cisco Nexus5010 Chassis ("20x10GE/Supervisor")
Intel(R) Celeron(R) M CPU with 2073416 kB of memory.
Processor Board ID JAF1228BTAS
Device name: BEND-2
bootflash: 1003520 kB
Kernel uptime is 0 day(s), 3 hour(s), 30 minute(s), 45 second(s)
Last reset
Reason: Unknown
System version:
Service:
plugin
Core Plugin, Ethernet Plugin, Fc Plugin
switch# conf t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# hostname NEXUS-SWITCH
NEXUS-SWITCH(config)#interface loopback0
NEXUS-SWITCH(config-if)# ip address 10.2.2.2/32
NEXUS-SWITCH(config-if)#end
NEXUS-SWITCH# show ip int brief
IP Interface Status for VRF “default” (1)
Interface IP Address Interface Status
Lo0 10.2.2.2 protocol-up/link-ip/admin-up
NEXUS-SWITCH#
IOS-XR:
RP/0/RP/CPU0:router# show version
Mon May 31 02:14:12.722 DST
Cisco IOS XR Software, Version 4.1.0[Default]
Copyright (c) 2010 by Cisco Systems, Inc.
ROM: System Bootstrap, Version 2.100(20100129:213223) [CRS-1 ROMMON],
router uptime is 1 week, 6 days, 4 hours, 22 minutes
System image file is "bootflash:disk0/hfr-os-mbi-4.1.0/mbihfr-rp.vm"
cisco CRS-8/S (7457) processor with 4194304K bytes of memory.
7457 processor at 1197Mhz, Revision 1.2
2 Management Ethernet
8 GigabitEthernet
12 SONET/SDH
12 Packet over SONET/SDH
1 WANPHY controller(s)
1 TenGigE
1019k bytes of non-volatile configuration memory.
38079M bytes of hard disk.
3607592k bytes of disk0: (Sector size 512 bytes).
3607592k bytes of disk1: (Sector size 512 bytes).
RP/0/RP/CPU0:router#conf t
RP/0/RP/CPU0: router(config)#hostname IOS-XR-ROUTER
RP/0/RP/CPU0: router(config)#interface loopback0
RP/0/RP/CPU0: router(config-if)#ip address 10.3.3.3/32
RP/0/RP/CPU0: router(config-if)#commit
RP/0/RP/CPU0: IOS-XR-ROUTER (config-if)#end
RP/0/RP/CPU0: IOS-XR-ROUTER (config)#show ip int brirf
Interface IP-Address Status Protocol Vrf-Name
Loopback0 10.3.3.3 Up Up default
MgmtEth0/0/CPU0/0 unassigned Shutdown Down default
GigabitEthernet0/0/0/0 unassigned Shutdown Down default
RP/0/RP/CPU0: IOS-XR-ROUTER#
Пока не создан единый протокол маршрутизации, управляющий остальными, существует необходимость в том, чтобы несколько протоколов маршрутизации мирно сосуществовали в одной сети. К примеру, одна компания работает с OSPF, а другая компания работает с EIGRP, и эти две компании слились в одно целое предприятие. Пока вновь образованный ИТ-персонал не перейдет для использования на единый протокол маршрутизации (возможно они когда-нибудь это сделают), маршруты, известные протоколу OSPF, необходимо объявить в часть сети, работающей под управлением EIGRP, и наоборот.
Упомянутый выше сценарий возможен благодаря Route redistribution, и именно этому посвящена данная статья. Другие причины, по которым вам потребуется выполнить Route redistribution, это: различные части сети конкретной компании находятся под различным административным контролем; если необходимо объявить маршруты своему поставщику услуг через BGP, или, возможно, необходимо подключиться к сети делового партнера.
Рассмотрим следующую базовую топологию.
В простой топологии, показанной выше, мы хотим, чтобы OSPF и EIGRP объявляли друг другу маршруты, о которых они знают. Эта концепция называется взаимным перераспределением маршрутов. Поскольку роутер CENTR имеет один интерфейс в автономной системе OSPF (AS) и один интерфейс в EIGRP AS, он несет ответственность за выполнение Route redistribution.
Seed Metrics
Основная проблема, с которой мы сталкиваемся при Route redistribution между различными протоколами маршрутизации, заключается в разнообразных подходах, применяемых протоколами маршрутизации для измерения своих метрик. Например, OSPF использует cost-метрику, которая основана на bandwidth, в то время как EIGRP использует метрику, основанную на bandwidth и delay, но также может учитывать надежность или (и) нагрузку (и даже использовать Maximum Transmission Unit (MTU) в качестве прерывания связи). Итак, что же нам делать?
Мы, как администраторы, можем настроить метрику, назначенную маршрутам, поступающим из одной AS, которые перераспределяются в другую AS. Если нам лень вручную настраивать метрику, которая будет использоваться для Route redistribution, то используется seed metric. В следующей таблице показаны seed metrics, используемые различными протоколами маршрутизации.
Основываясь на приведенной выше таблице, мы видим, что, маршрутам, которые перераспределяются в OSPF по дефолту будет назначена метрика 20, если же маршруты, перераспределяются в протокол OSPF от протокола BGP, то им будет присвоено значение метрики 1. Интересно, что и RIP, и EIGRP по умолчанию имеют seed metrics бесконечности. Это означает, что любой маршрут, перераспределенный в эти протоколы маршрутизации, будет считаться недостижимым по умолчанию и поэтому не объявляются никаким другим роутерам. BGP, однако, перераспределяет маршрут, полученный из протокола внутреннего шлюза (IGP), используя исходную метрику этого маршрута.
Пример базовой настройки
Конечно, есть еще много вопросов, связанных с перераспределением маршрутов, таких как циклы маршрутизации, которые могут возникнуть, когда у нас есть несколько роутеров, соединяющих наши автономные системы, или выборочная фильтрация определенных маршрутов от перераспределения. Но мы вернемся ко всему этому в следующих статьях. А пока давайте разберемся, как выполнить базовую настройку Route redistribution (перераспределения маршрутов). Рассмотрим предыдущую топологию, на этот раз с добавлением информации о сети и интерфейсе:
В этой топологии роутер CENTR изучает маршруты от OFF1 через OSPF и от OFF2 через EIGRP. Это видно в выходных данных команды show ip route, отображенной на CENTR:
Однако ни роутер OFF1, ни роутер OFF2 не изучили никаких маршрутов, потому что роутер CENTR еще не выполняет Route redistribution. Об этом свидетельствует вывод команды show ip route, отображенной на OFF1 и OFF2:
Теперь давайте добавим конфигурацию Route redistribution к роутеру CENTR. Чтобы подтвердить предыдущее утверждение о том, что seed metric для маршрутов, перераспределяемых в EIGRP, является бесконечностью, мы изначально не будем настраивать какие-либо метрики и позволим seed metric вступить в силу.
CENTR# conf term
Enter configuration commands, one per line. End with CNTL/ Z
CENTR(config)#router ospf 1
CENTR(config-router)#redistribute eigrp 1
CENTR(config-router)#exit
CENTR(config)#router eigrp 1
CENTR(config-router)# redistribute ospf 1
CENTR(config-router)#end
CENTR#
Команда redistribute применена в режиме конфигурации роутера для каждого протокола маршрутизации, и метрика не была указана. Важно, что, когда мы ввели команду redistribute eigrp 1 выше, мы не включили ключевое слово subnets в команду, которая заставляет как классовые, так и бесклассовые сети перераспределяться в OSPF. Однако, как видно из приведенных ниже выходных данных, ключевое слово subnets было автоматически добавлено для нас:
Данное поведение автоматического добавления ключевого слова subnets наблюдается в последних версиях Cisco IOS. Некоторые, более старые версии Cisco IOS, не включают автоматически ключевое слово subnets, и вам может потребоваться вручную добавить его в команду redistribute. Давайте теперь взглянем на таблицы IP-маршрутизации на роутерах OFF1 и OFF2, чтобы увидеть, какие маршруты они изучили (и не изучили).
Приведенные выше выходные данные показывают нам, что роутер CENTR успешно перераспределил маршруты, известные EIGRP в OSPF, которые затем были изучены роутером OFF1. Обратите внимание, что перераспределенные маршруты, известные роутеру OFF1, имеют метрику 20, которая является seed metrics OSPF. Однако роутер OFF2 не изучал никаких новых маршрутов, потому что, когда роутер CENTR перераспределял маршруты в EIGRP, он использовал seed metrics EIGRP бесконечность (что означает недостижимость). В результате эти маршруты не были объявлены роутеру OFF2.
Чтобы решить эту проблему, нам нужно назначить метрику маршрутам, перераспределяемым в EIGRP. Существует три основных способа присвоения не дефолтных метрик маршрутам, перераспределяемым в протокол маршрутизации..
Установите метрику по умолчанию для всех протоколов маршрутизации, перераспределяемых в определенный протокол маршрутизации.
Установите метрику как часть команды redistribute.
Установите метрику используя route-map
Чтобы проиллюстрировать первый вариант, давайте настроим метрику для назначения всем маршрутам, перераспределяемым в EIGRP.
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR (config)#router eigrp 1
CENTR (config-router)#default-metric ?
1-4294967295 Bandwidth in Kbits per second
CENTR (config-router)#default-metric 1000000 ?
0-4294967295 delay metric in 10 microsecond units
CENTR(config-router)#default-metric 1000000 1 ?
0-255 Reliability metric where 255 is 100% reliable
CENTR (config-router)#default-metric 1000000 1 255 ?
1-255 Effective bandwidth metric (Loading) where 255 is 100% loaded
CENTR (config-router)#default-metric 1000000 1 255 1 ?
1-65535 Maximum Transmission Unit metric of thenpath
CENTR (config-router)#default-metric 1000000 1 255 1 1500
CENTR (config-router)#end
CENTR#
Контекстно-зависимая справка была использована в приведенном выше примере для отображения каждого компонента метрики, назначаемого маршрутам, перераспределяемым в EIGRP. Однако последняя команда была default-metric 1000000 1 255 1 1500. Если бы мы устанавливали default-metric для OSPF, мы могли бы использовать такую команду, как default-metric 30, чтобы назначить стоимость 30 OSPF маршрутам, перераспределяемым в OSPF. Однако в этом примере мы указали только default-metric для EIGRP. Давайте теперь проверим таблицу IP-маршрутизации на роутере OFF2, чтобы увидеть, были ли маршруты OSPF успешно объявлены в EIGRP.
Прекрасно! Роутер OFF2 изучил маршруты, происходящие из OSPF AS. Мы знаем, что маршруты первоначально пришли из-за пределов EIGRP, из-за кода EX, появляющегося в каждом из этих маршрутов.
Второй вариант установки метрики на Route Redistribution состоял в том, чтобы назначить метрику как часть команды redistribute, которая позволяет нам указать различные метрики для различных протоколов маршрутизации, перераспределяемых в процесс маршрутизации. Чтобы проиллюстрировать этот подход, давайте удалим предыдущие команды default-metric и redistribute из роутера CENTR и введем команду redistribute, которая определяет метрику, которая будет назначена.
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR(config)#router eigrp 1
CENTR(config-router)#no default-metric 1000000 1 255 1 1500
CENTR(config-router)#no redistribute ospf 1
CENTR(config-router)#redistribute ospf 1 ?
Match Redistribution of OSPF routes
metric Metric for redistributed routes
route-map Route map reference
cr
CENTR(config-router)#redistribute ospf 1 metric 1000000 1 255 1 1500
CENTR(config-router)#end
CENTR#
Если мы сейчас вернемся к роутеру OFF2, то получим тот же результат, что и раньше:
Третьим вариантом установки метрики для Route Redistribution использовании маршрутной карты (route-map). Маршрутные карты являются супермощными и могут быть использованы для различных конфигураций. По сути, они могут соответствовать определенному трафику и устанавливать один или несколько параметров (например, IP-адрес следующего прыжка) для этого трафика. Однако в нашем контексте мы просто будем использовать route-map для указания значения метрики, а затем применим ее к команде redistribute. В следующем примере показано, как мы можем удалить нашу предыдущую команду redistribute из роутера CENTR, создать route-map, а затем ввести новую команду redistribute, которая ссылается на нашу карту маршрута (route-map):
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR(config)#router eigrp 1
CENTR(config-router)#no redistribute ospf 1 metric 1000000 1 255 1 1500
CENTR(config-router)#exit
CENTR(config)#route-map SET-МETRIC-DEMO
CENTR(config-route-map)#set metric 1000000 1 255 1 1500
CENTR(config-route-map)#exit
CENTR(config)#router eigrp 1
CENTR(config-router)#redistribute ospf 1 route-map SET-МETRIC-DEMO
CENTR(config-router)#end
CENTR#
В приведенном выше примере, после удаления нашей команды redistribute, мы создали карту маршрута с именем SET-METRIC-DEMO. Это был очень простой route-map, которая не должна была соответствовать никакому траффику. Он был просто использован для установки метрики. Однако в следующей статье мы увидим, что route-map может быть использована, чтобы дать нам больше контроля над нашим перераспределением маршрутов. В нашем текущем примере карта маршрута была затем применена к нашей новой команде redistribute. Опять же, это дает нам тот же результат с точки зрения таблицы IP-маршрутизации роутера OFF2:
OSPF E1 или E2 Routes
Прежде чем мы закончим эту статью в нашей серии Route redistribution, давайте еще раз рассмотрим таблицу IP-маршрутизации на роутере OFF1:
Обратите внимание, что каждый из маршрутов, перераспределенных в OSPF, отображается в таблице IP-маршрутизации роутера OFF1 с кодом E2. Однако наблюдаются также код E1, оба указывающих, что маршрут возник из-за пределов OSPF AS роутера. Итак, в чем же разница между этими двумя кодами?
Код E2 указывает, что маршрут несет метрику, назначенную роутером, выполняющим перераспределение, который известен как автономный системный пограничный роутер (ASBR). Это означает, что независимо от того, сколько дополнительных роутеров в OSPF мы должны пересечь, чтобы вернуться к ASBR, метрика остается такой же, какой она была, когда ASBR перераспределил ее. Когда мы перераспределяем маршруты в OSPF, эти маршруты, по дефолту, являются этими External Type 2 (E2).
Код E1 указывает, что метрика маршрута состоит из первоначальной стоимости, назначенной ASBR, плюс стоимость, необходимая для достижения ASBR. Это говорит о том, что маршрут Е1, как правило, более точен, и на самом деле это так. Хотя наличие кода E1 не дает нам никакого преимущества в простой топологии, как у нас, где роутер OFF1 имеет только один путь для достижения ASBR (т. е. CENTR), и где есть только один способ для маршрутов EIGRP быть введенными в наш OSPF AS (т. е. через роутер CENTR).
Если мы хотим перераспределить маршруты E1 в OSPF вместо маршрутов E2, то это можно сделать с помощью команды redistribute. В следующем примере мы удаляем нашу команду redistribute для процесса маршрутизации OSPF на роутере CENTR, а затем повторно применяем команду redistribute, указывающую, что мы хотим, чтобы External Type 1 (E1) применялись к перераспределенным маршрутам.
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR(config)#router ospf 1
CENTR(config-router)#no redistribute eigrp 1 subnets
CENTR(config-router)#redistribute eigrp 1 metric-type ?
1 Set OSPF External Туре 1 metrics
2 Set OSPF External Туре 2 metrics
CENTR(config-router)#redistribute eigrp 1 metric-type 1
CENTR(config-router)#end
CENTR#show
Давайте проверим таблицу IP-маршрутизации на роутере OFF1, чтобы увидеть, изменились ли параметры на основе этой новой команды redistribute, введенной на роутере CENTR.
В приведенных выше выходных данных обратите внимание, что маршруты, перераспределенные в OSPF, имеют код E1, а не дефолтный код E2. Кроме того, обратите внимание, что это приводит к тому, что метрика этих маршрутов будет немного выше. В частности, роутер CENTR перераспределил EIGRP-изученные маршруты в OSPF, используя начальную метрику OSPF 20.
Однако существует стоимость OSPF 1, чтобы добраться от роутера OFF1 до роутера CENTR. Таким образом, поскольку перераспределенные маршруты были сконфигурированы как маршруты E1, стоимость этих маршрутов с точки зрения роутера OFF1 является стоимостью, первоначально назначенной роутером OFF1, которая составляла 20, плюс стоимость для OFF1, чтобы добраться до CENTR, который равен 1, итого общей стоимости 21.
Отлично, теперь вы знаете, как делать перераспределение маршрутов. Теперь почитайте, как сделать Фильтрацию маршрутов с помощью карт маршрутов.
Привет всем! В сегодняшней статье хотим рассказать о том, как защитить исходящие маршруты во FreePBX списком паролей. Мы покажем, как создать множество PIN-кодов, которые необходимо будет набрать прежде чем открылась возможность совершения вызова через тот или иной исходящий маршрут.
Как можно догадаться, для этих целей во FreePBX существует специальный модуль - PIN Sets, о нём и поговорим.
Обзор
Модуль PIN Sets позволяет создавать группы и привязывать к ним список определённых паролей (нас самом деле - PIN-кодов). Затем, через модуль Outbound Route можно сократить пользование исходящим маршрутом только до определённой группы. Получается такое расширение функций поля Route Password в настройках исходящего маршрута только вместо одного PIN-кода мы теперь можем ввести много разных.
Например, мы можем создать группу ”Sales” (Продавцы) и задать в ней 3 PIN-кода, один для руководителя отдела продаж, и ещё два для менеджеров, а затем каждому сообщить свой PIN. Потом назначить данную группу на определённый маршрут и каждый раз, когда кто-то захочет сделать внешний вызов через этот маршрут, ему будет предложено сначала ввести PIN.
Настройка
Перейдём к настройке. Модуль PIN Sets располагается в разделе Settings:
Описание модуля говорит нам, что он используется для управления PIN-кодами для доступа к “запрещённым фичам” таким как Outbound Routes (исходящие маршруты). Но на самом деле, кроме как в модуле Outbound Route функционал PIN Sets больше нигде применить нельзя.
Существует коммерческая реализация данного модуля – PIN Sets Pro. Она позволяет создавать наборы PIN-кодов индивидуально для внутренних номеров, а также строит отчёты по использованию данных PINов.
Для того, чтобы создать новую группу кликаем Add Pinset:
Перед нами открывается окно с параметрами для добавления новой группы:
Описание каждого параметра модуля:
PIN Set Description - Описание для данной группы;
Record In CDR - Параметр, отвечающий за то, записывать ли PIN-коды данной группы в CDR;
PIN List - Собственно, сами PIN коды, которые можно будет набрать прежде чем звонить через маршрут. Можно вводить несколько PIN-кодов, записывая их в линию;
После создания новой группы нажимаем Submit и Apply Config. А затем отправляемся в модуль Outbound Route, выбираем из списка маршрут, который нужно защитить и открываем его настройки. Предварительно, необходимо убедиться, что на вкладке Route Settings в поле Route Password не стоит никакого пароля.
Переходим на вкладку Additional Settings и в поле PIN Sets выбираем только что созданную группу.
Теперь, чтобы можно было воспользоваться маршрутом 79012345678 и позвонить во вне, абоненту нужно будет набрать либо PIN-код 48151 либо 62342 как настроено в PIN Sets.
Каждому исходящему маршруту может быть назначена только одна группа PIN Set. Если Вы хотите разрешить ещё одной группе пользоваться тем же маршрутом, не внося пароли из неё в первую группу, просто продублируйте маршрут и назначьте ему новую группу PIN Set.