Cisco cube что это
Обновлено: 07.07.2024
Какие настройки необходимо сделать на маршрутизаторе, чтобы у вас зазвонил первый IP телефон? Данная статья приводит краткую теорию, и приводит практические шаги, необходимые для построения телефонной сети на основе Cisco Call Manager Express.
В первой части мы рассматриваем самые основные настройки CUCME.
Рассматриваются шаги загрузки телефона и методы диагностики проблем в среде CUCME.
Шаги загрузки IP Phone
Очевидно, как минимум, мы должны дать возможность телефону нормально загрузиться, поэтому рассмотрим шаги его загрузки.
(1). Cisco IP Phone подключается к порту коммутатора. Если телефон и коммутатор поддерживают стандарт PoE, IP телефон получает питание от кабеля Ethernet. Если нет, то телефон нужно запитать от розетки.
(2). При включении коммутатор Cisco по CDP отдает телефону информацию о voice VLAN.
(3). Телефон шлет DHCP-запрос на его voice VLAN. Сервер DHCP отдает информацию адресации, включая IP address, subnet mask, default gateway, DNS server и т.д. Тут следует отметить что телефон также получает от DHCP так называемую option 150. Это особая опция, которая включает в себя адреса TFTP серверов.
(4). После того как телефон получил информацию о сервере TFTP, он к нему подключается и загружает конфигурационный файл. Конфигурационный файл в себя включает список серверов Call Processing Agents или попросту CUCME, которых может быть несколько.
(5). IP телефон подключается к Call Processing Server или к CUCME.
Рассмотрим практический пример со схемой представленной ниже:
В данном примере мы настроим маршрутизатор c2951 и коммутатор c2950 так, чтобы у нас зазвонили IP телефоны.
(1) Настройка Voice VLAN
В нашей сети имеются как компьютеры, так и телефоны.
Мы создадим два VLAN-a:
VLAN 10 для компьюетров
VLAN 20 для телефонов
Собственно VLAN 20 и будет называться как Voice VLAN.
Т.к. у коммутатора кофигурация отсутствовала, минимальные настройки:
hostname c2950
vtp mode transparent
Создадим VLAN-ы
vlan10
name comp
vlan 20
name voip
Настроим порты коммутатора для телефонов:
interface FastEthernet0/1
switchport access vlan 10
switchport mode access
switchport voice vlan 20
spanning-tree portfast
!
interface FastEthernet0/2
switchport access vlan 10
switchport mode access
switchport voice vlan 20
spanning-tree portfast
По сути при такой настройке между портом и телефоном поднимается транк, т.е. через одно соединение идет трафик обоих VLAN-ов.
На рисунке видно, что трафик компьтера, т.е. VLAN 10 никак не тагируется и передается компьютеру, при этом телефон работает как обычный коммутатор.
Трафик VLAN 20 же тагируется. Это позволяет в одном линке пересылать фреймы обих VLAN-ов.
Маршрутизатор в данной схеме является шлюзом по умолчанию для обоих подсетей. Поэтому соединение маршрутизатора и коммутатора будет транковым
Настройки коммутатора:
interface FastEthernet0/24
switchport mode trunk
Настройки порта маршрутизатора:
interface GigabitEthernet0/0
no ip address
duplex auto
speed auto
!
interface GigabitEthernet0/0.10
description Comp
encapsulation dot1Q 10
ip address 10.0.10.1 255.255.255.0
!
interface GigabitEthernet0/0.20
description voip
encapsulation dot1Q 20
ip address 10.0.20.1 255.255.255.0
Прочие настройки: настроим на коммутаторе IP адрес и доступ
interface Vlan10
ip address 10.0.10.5 255.255.255.0
username admin privilege 15 password 0 adm
line vty 0 4
privilege level 15
enable secret 0 adm
Аналогичные настройки дадим на c2951
aaa new-model
username admin privilege 15 password 0 adm
line vty 0 4
privilege level 15
enable secret 0 adm
Таким образом, на данном этапе маршрутизатор уже должен успешно пинговать адрес коммутатора:
Если подключить телефон, то он конечно включится, но будет отображать "Phone not Registered".
У него еще нет IP настроек, которые он должен получить от сервера DHCP.
Мы в этом кстати можем убедиться, заглянув в сам телефон и выбрав Phone Information - там поле IP адреса будет пустым.
Также можно на коммутаторе дать команды:
show cdp neighbors
show cdp entry
(2) Настройка DHCP сервиса
В качестве DHCP сервера сделаем маршрутизатор.
Мы создадим два пула на маршрутизаторе.
ip dhcp excluded-address 10.0.10.1 10.0.10.10
ip dhcp excluded-address 10.0.20.1 10.0.20.10
!
ip dhcp pool VOIP_SCOPE
network 10.0.20.0 255.255.255.0
default-router 10.0.20.1
option 150 ip 10.0.20.1
dns-server 10.0.10.1
!
ip dhcp pool COMP_SCOPE
network 10.0.10.0 255.255.255.0
default-router 10.0.10.1
dns-server 10.0.10.1
Отметим здесь наличие опции 150 в настройках VOIP_SCOPE. Эта опция указывает телефону на TFTP сервер, откуда будет подгружаться конфигурация телефона.
Также в обоих скопах мы исключили адреса 1 - 10, зарезервировав их для тех нужд (сервера, коммутаторы и т.д.)
На этом этапе уже можно включить телефон. Он загрузится, но будет отображать Phone not Registered, т.к. мы еще не настроили ни TFTP сервер, ни CUCME.
Тем не менее телефон и компьютер уже получат свои IP адреса.
На телефоне это можно посмотреть нажав:
* -> Phone Information -> Ip Address
На коммутаторе телефон будет виден по CDP:
Тут следует выделить поля Unified CM 1 и 2 это собственно есть список Call Processing Agents, который телефон должен подгрузить из сервера TFTP. Сервер TFTP-то у нас получен (через опцию 150), но сам сервер еще не настроен.
Настройка DNS server
DNS сервер необходим телефону для разрешения имени CUCME в IP адрес. Вообще с именами лучше не связываться и везде прописывать именно IP адрес, но DNS сервис нужно все же настроить в любом случае. Им могут пользоваться не только телефоны но и компьютеры.
Настроим маршрутизатор в качестве кеширующего DNS сервера:
ip domain lookup
ip domain timeout 2
ip domain name office.local
ip host c2951 10.0.20.1
ip host c2951.office.local 10.0.20.1
ip name-server 8.8.8.8
ip name-server 8.8.4.4
ip dns server
ip domain lookup - включает трансляцию имён в ip адреса основанную на dns. Этот параметр включен по умолчанию. Часто его выключают чтобы маршрутизатор не "зависал" при вводе ошибочной команды, но для нашей цели его необходимо включить.
ip name-server - этот параметр задаёт адрес одного или нескольких серверов имён (dns). Приоритет определяется сверху вниз.
Автор тут включил общедоступные сервера (8.8.8.8 и 8.8.4.4), вы же можете сюда добавить сервера предоставляемые местным провайдером.
ip domain name - задаёт имя домена по умолчанию для пользователей Cisco IOS software для разрешения "неопознаных" доменных имён (имена без суффикса.
ip dns server - включаем собственно кеширующий DNS сервер на циске
Конструкция ip host c2951 10.0.20.1 работает подобно файлу hosts в windows.
Мы прописали имена c2951 и c2951.office.local как раз на случай если кто-то полезет на это имя. Такое бывает иногда с MGCP или в настройках CUCM.
Настройка DNS server подразумевает подключение маршрутизатора к интернет тем или иным способом, что выходит за рамки данной статьи.
Настройка NTP
Настройка точного времени необходима в работе множества сетевых сервисов.
К примеру точные значения времени играют важную роль в различных сервисах безопасности, в отображении логов.
При использовании CUCME время отображается на телефонах, во временных метках голосовой почты или записях CDR.
В большой сети и при большом количестве устройств имеет смысл синхронизировать одно или два "главных" устройства с источниками извне, а все остальные в свою очередь синхронизировать с мастерами.
На маршрутизаторе вводим команды и сделаем его "главным":
service timestamps log datetime
clock timezone MSK 4
ntp master 2
ntp update-calendar
ntp server 64.90.182.55
ntp server 62.117.76.138
ntp server 81.2.117.228
ntp server 88.147.254.228
Настройка NTP подразумевает подключение маршрутизатора к интернет тем или иным способом, что выходит за рамки данной статьи.
Настройка сервера TFTP
Во время загрузки IP телефону необходимо связаться с сервером TFTP.
В общем случае TFTP сервер не обязательно совпадает с CUCME, т.к. маршрутизатор не спроектирован на обслуживание большого количества телефонов, да и объем Flash не бесконечен. Но в нашем случае мы запустим TFTP на все том же маршрутизаторе.
По сути, сервер TFTP играет роль файлового сервера в сети телефонии. Телефоны загружают с него файлы конфигурации, а также файлы прошивок.
Файлы конфигурации включают в себя такую информацию как IP адреса и порты серверов CUCME, а также имена файлов прошивки, которые должен загрузить телефон.
Файлы конфигурации индивидуальны для каждого телефона, но при первом подключении таковой отсутствует. В этом случае телефон загружает файл по умолчанию: XMLDefault.cnf.xml. Затем в процессе регистрации CUCME создает уже индивидуальный файл, которым телефон уже будет пользоваться в штатном режиме.
Файлы прошивки необходимо загрузить с сайта Cisco.
Например для телефона 6961 файлы будут:
SCCP69xx.9-0-3-b.loads
BOOT69xx.0-0-0-14.zz.sgn
DSP69xx.0-0-0-3.zz.sgn
SCCP69xx.9-0-3-0-b.zz.sgn
Их необходимо скопировать на Flash
затем дать команды на маршрутизаторе :
tftp-server flash:SCCP69xx.9-0-3-b.loads
tftp-server flash:BOOT69xx.0-0-0-14.zz.sgn
tftp-server flash:DSP69xx.0-0-0-3.zz.sgn
tftp-server flash:SCCP69xx.9-0-3-0-b.zz.sgn
Активируем сервис CUCME, поочередно даём следующие команды:
telephony-service
max-ephones 24
max-dn 48
ip source-address 10.0.20.1 port 2000
cnf-file location flash:
load 6921 SCCP69xx.9-0-3-b.loads
load 6941 SCCP69xx.9-0-3-b.loads
load 6961 SCCP69xx.9-0-3-b.loads
create cnf-files
Поочерёдно потому, что некоторые команды будут требовать подтверждения лицензионного соглашения.
Отметим смысл некоторых команд:
max-ephones 24 - максимальное количество телефонов которое маршрутизатор будет поддерживать.
max-dn 48 - максимальное количество номеров.
max-ephones и max-dn влияют на количество выделяемой памяти; также параметр не должен быть больше количества приобретенных feature licenses.
ip source-address - определяет на каком адресе маршрутизатор будет ожидать регистраций.
cnf-file location flash: - определяет местоположение конфигурационных файлов
create cnf-files - после этой команды будут созданы конфигурационные файлы
load - команда определяет какая модель телефона будет использовать какую прошивку. Без этой команды телефон будет использовать имеющуюся прошивку и не будет пытаться обновиться.
На самом телефоне мы увидим:
Телефон зарегистрировался, но мы еще не настроили номер, поэтому на экране он не отображается, а только дата и время. Если поднять трубку - она не загудит.
Настройка Ephone и Ephone-DN
В среде CUCME есть понятия Ephone и Ephone-DN.
Ephone - это объект в системе CUCME имеющий отношение к физическому телефону. Система различает Ephone друг от друга их MAC адресами.
Ephone-DN - представляет номер линии, или Directory Number. Физический телефон в общем случае может иметь несколько линий, т.е. до него можно дозвониться по нескольким номерам.
Настроим ephone-dn для нашего телефона:
ephone-dn 1 dual-line
number 101
description Natalia Askarova
name Natalia Askarova
Настроим ephone для нашего телефона:
ephone 1
mac-address C84C.759C.B7A7
type 6961
button 1:1
Здесь мы привязали физический телефон к объекту ephone 1 через его MAC адрес.
MAC адрес можно посмотреть в меню телефона Settings.
button
- данная команда привязывает номер ephone-dn к физической кнопке телефона. Т.е. при входящем звонке эта кнопка будет мигать. В нашем случае команда button 1:1 привязывает к первой кнопке ephone-dn 1.
После подобных изменений телефон необходимо перезагрузить, это можно сделать двумя способами:
- Телефон по питанию
- Зайти conf t > ephone 1 > restart
После перезагрузки телефон уже будет отображать свой номер.
Теперь мы можем проверить настройку нашего телефона:
show ephone
Аналогично мы можем настроить второй телефон. И теперь телефоны смогут осуществлять звонки друг другу.
Настройка телефона с помощью CCP
Cisco Configuration Professional (CCP) - это графическая оснастка, позволяющая конфигурировать маршрутизатор вне командной строки.
Для доступа к глобальным установкам CUCME идем по пути:
Configure - Unified Comunications - Telephony settings
Для настройки номера телефона идем:
Configure - Unified Comunications - Users, Phones and Extensions > Extension > Create
После этого настраиваем физический телефон:
Configure - Unified Comunications - Users, Phones and Extensions > Phones and Users
Cisco Unified Border Element Version 14 Data Sheet
Part of the Cisco ® Collaboration Edge Architecture, Cisco Unified Border Element (CUBE) version 14 is an enterprise-class Session Border Controller (SBC) solution that makes it possible to connect and interwork large, midsize, and small business unified communications networks with public and private IP communication services.
As a licensed feature set of Cisco IOS ® XE Software, CUBE has a wide range of capabilities that may be used to secure, monitor, and maintain business-critical connections and to ensure compliance with industry standards. Collectively, CUBE features provide exceptional flexibility when architecting highly available enterprise communications networks that save money and offer richer voice and video collaboration experiences to users.
As voice, video, and mobile communications systems converge to form more cost-effective, integrated collaboration solutions, the need to interwork diverse networks based on various protocols and security requirements increases. The CUBE SBC serves a critical role in linking these networks and provides a seamless experience for voice and video users.
CUBE is especially suited to facilitating:
● PSTN interconnect using Internet service provider SIP trunks, which allow rapid service delivery and the possibility of capacity pooling across locations.
● Migration from TDM to SIP public telephony trunk services. As a number of Cisco routers allow the concurrent use of voice gateway and CUBE features, a phased trunk migration is possible without requiring changes to the enterprise call control platform.
● Certified connection to Cisco and third-party cloud collaboration services, including Cisco Webex ® Cloud Connected Audio (CCA and CCA-SP), Webex Calling Local Gateway, Cisco Hosted Collaboration Solution (HCS) and Direct Routing for Microsoft Phone System (Microsoft Teams), with normalization to customer collaboration systems. CUBE supports high-capacity SIP media connectivity to the Cisco Webex cloud to replace expensive TDM audio connections to conferencing services.
● Business-to-business voice and video system interconnect.
● Multi-tenant solutions that require customer-dedicated SIP trunks on a common platform.
● Codec interworking through the control of midcall codec renegotiation or transcoding.
Note: Cisco Unified Communications Manager customers requiring business-to-business video features should use Cisco Expressway ™ .
As CUBE terminates and re-originates signaling and media traffic, it is able to provide a secure demarcation between internal and external services, while interworking signaling protocols and encoded media streams between them. Further, CUBE provides a rich set of flexible session control features to secure and route traffic to different destinations and to apply policing and Quality-of-Service (QoS) policies.
Certain CUBE features may also be used with Cisco Communications Manager Express (CME) and Unified Survivable Remote Site Telephony (SRST) applications to connect with SIP trunk services.
Security and compliance
As networks become more interconnected, the need to secure information is of critical importance. Enterprises must comply with rapidly evolving industry standards for the proper handling and protection of sensitive and private information and for the proper auditing of commercial transactions. The comprehensive CUBE SBC feature set helps businesses achieve these requirements with:
● Flexible security rules that prohibit unauthorized connections.
● Behavior evaluation policies that can detect malicious call patterns, including Telephony Denial-of-Service (TDoS) attacks, and invoke an appropriate response – such as terminate, redirect, or record.
● Interworking of encrypted and non-encrypted communication streams.
Cloud communications services
Cloud call control products offer simple-to-provision-and-manage services. However, by their very nature, these services place a greater dependency on the wide-area connections required at customer sites. While additional bandwidth and redundant connectivity can mitigate this requirement, service providers can also use CUBE lineside features to ensure continued service delivery.
● CUBE registration proxy can manage periodic messaging from Cisco Multiplatform Phones (MPP) or third-party SIP endpoints, reducing demand on wide-area connections and permitting larger deployments of endpoints.
● Lineside survivability provides business continuity to SIP phones on a customer site should connectivity to the cloud service be interrupted.
Note: CUBE lineside features are offered for use with SIP-based, IP Centrex solutions (such as Cisco BroadCloud ® ). They cannot be used with Cisco Unified Communications Manager, where Expressway and Unified Survivable Remote Site Telephony products should be considered.
Contact center solutions
CUBE offers numerous features that may be used to architect and optimize fully featured contact center solutions. Examples include:
● Call Progress Analysis (CPA) for outbound calling campaigns
● Interactive Voice Response (IVR) solutions
● Media replication for call recording and analysis
Flexibility, Reliability, and Scale
Cisco offers industry-leading flexibility when it comes to deploying SBC functionality in almost any enterprise architecture. As CUBE is offered as part of Cisco IOS XE Software, it may be used concurrently with industry-leading IP networking, security, and QoS features. You can also choose from a wide range of host platforms to suit scale, performance, resiliency, and budget requirements (see Table 2).
In addition to physical hosts from Cisco Integrated Services Router (ISR), Cisco Catalyst ® Edge Routers and Aggregation Services Router (ASR) product families, CUBE features are available for virtualized environments with the Cisco Cloud Services Router (CSR) and Catalyst Edge Software.
Stateful high availability with active/standby redundant pairs and clustering with Cisco Unified SIP Proxy allows enterprises to build highly scalable, business-critical solutions.
The CUBE features described above are licensed to enable three principal use models:
● Trunking for service interconnect and protocol interworking. Trunk licenses are available for both standard (single node) and enhanced (high-availability and advanced features) network architectures to facilitate site-to-site and PSTN connectivity. Each trunk license enables a single call session in addition to a single forked media session for recording where required.
● Lineside to enhance the delivery of hosted SIP communications services. Previously only available for the Cisco 800 Series Routers through the NanoCUBE license, CUBE Lineside client licenses are now available for all platforms listed in Table 2. Each Lineside license enables registration proxy and survivability features for one local SIP endpoint.
● Media Proxy for advanced call recording and compliance solutions. Deployed independently from CUBE platforms configured for trunkside or lineside applications, CUBE Media Proxy allows corporate customers to meet compliance requirements by simultaneously recording or analyzing calls at up to five destinations simultaneously. Each Media Proxy license enables one forked media session in either standard or redundant configurations.
CUBE Smart Licenses allow for entitlement pooling and portability across all CUBE platforms registered to an organization’s Cisco Smart Licensing account. Providing further flexibility, Cisco Smart Licensing also allows the borrowing of higher-entitlement CUBE licenses if required.
CUBE feature support
CUBE supports a comprehensive range of session control, security, interworking, and demarcation SBC features, many of which are detailed in Table 1.
Cisco CUBE и Tenants. Описание
24 марта 2016 года можно считать праздником инженеров, поддерживающих Cisco CUBE, поскольку в этот день был выпущен релиз IOS 15.6.2T.
Начиная с этого релиза было введено понятие Tenant.
До этого времени настройка одновременной работы нескольких SIP провайдеров была самой настоящей головной болью:
Настройки параметров нескольких провайдеров должны были производиться только на глобальном уровне.
Логины/пароли для всех ITSP должны производиться только на уровне одного SIP-UA и часто перезаписывали и конфликтовали друг с другом.
В результате если настройка одного ITSP с одним номером была относительно несложна, то при необходимости настройки двух ITSP и более, начинались пляски с бубном и подчас всё упиралось в тупое перебирание комбинаций параметров номера, username, пароля и realm-а. Cisco же на полном серьёзе рекомендовала для второго провайдера устанавливать второй CUBE.
Этот факт вызывал как минимум недоумение у специалистов, знающих VoIP АТС от других производителей; а иногда заставлял заменять CUBE на отдельный хост Asterisk, способный вменяемо разруливать звонки между несколькими провайдерами.
И вот Cisco CUBE научился делать то, что от него так долго ждали:
Tenant позволяет настроить параметры каждого логина для каждого провайдера обособленно и независимо друг от друга, и затем подключать их на уровне Dial-peer.
Далее мы приведём пример реальной настройки Cisco CUBE + Tenants на примере подключения к ITSP Beeline в РФ.
Также в данном материале приведены рекомендуемые Cisco best practices для настроек SIP Voice Service, диалпиров и безопасности.
CUBE и SRST
dial-peer voice 4 voip
translation-profile incoming INBOUND
preference 3
destination-pattern 6673
session target ipv4:10.15.20.250 (Loopback роутера c CUBE)
incoming called-number XXXXXXXXXXXX
voice-class codec 1
dtmf-relay rtp-nte
ip qos dscp cs3 signaling
SRST + Gateway
Не совсем верно. С таким конфигом вы получите лишнюю ногу.
У себя я делаю входящие так:
Спасибо. У меня доступность
Спасибо. У меня доступность CUCM проверяется keepalive на dialpeer и если связь падает то отрабатывает SRST dialpeeer с большим preference
dial-peer voice 1 voip
destination-pattern 883140776.
session protocol sipv2
session target ipv4:CUCM
voice-class codec 1
voice-class sip options-ping 60
voice-class sip options-keepalive
dial-peer voice 4 voip
translation-profile incoming INBOUND
preference 1
destination-pattern 6673
session protocol sipv2
session target dns:SIP-ISP
incoming called-number 883140776.
Чтоб два раза не вставать )))
Чтоб два раза не вставать )))
Пытаюсь настроить CUBE для работы внутри vrf. Есть два ISP, каждый из них убран в отдельную vrf, интерфейс в сторону пользователей тоже в своей vrf (все это сделано для корректной работы spoke-spoke dmvpn c 2мя isp).
Маршрут от провайдеров реплицируется в пользовательский vrf.
Так как voice vrf может быть только один. Я биндю sip на внутрений интерфейс и пробрасываю 5060 внутрь.
spoke-spoke dmvpn c 2мя isp
Если не секрет, можно поподробней, почему вы выбрали путь именно с vrf для работы с двумя ISP?
И как реализовано переключение на резервный (интернет, туннели).
Чтоб два раза не вставать )))
Пытаюсь сейчас настроить такую же схему, когда 2 врф на 2 провайдер. Телефоны заставил звонить и разговаривать друг с другом. Но вот проблема в том, что не могу заставить звонить и принимать звонки от сип провайдера. не подскажите, куда смотреть?
2 врф на 2 провайдер
ИМХО с цискиным SIP-ом и так хватает причуд и гемора. Всё это ещё помножить на 2ВРФ имеет смысл разве что ради академического интереса.
При в взаимодействии с другим
При в взаимодействии с другим споком у которого тоже 2 ISP, когда падает один из провайдеров на одном, а у второго спока default route и активный туннель остается в то же облако dmvpn,то не строится isakmp через 2 второго провайдера от первого спока, т.к второй спок отвечает через default маршруту, команда tunnel route-via xxx mandatory не влияет на isakmp. Можно решить прописыванием дефолтов до вторых ISP или vrf. Я в итоге сделал через ip local policy route-map
Намудрил нехило
А переключать через IP SLA не пробовал?
Хотя главное чтоб работало
На самом деле не работает
Под ip local policy не попадает esp и соответственно туннель поднимается а трафик не идет.
Думаю уже отказаться от Phase2-3 на этой площадке.
Второй вариант хорош но не учитывает ситуации если в инет выходят прямо через спок (борется 3им vrf) и route-replicate в него. Но при таком варианте не работает CUBE
To toxa
Как мне поможет ip-sla?))
ip-sla
"По умолчанию на всех споках default-route через облако red. Допустим на споке 1 падает основной провайдер. При связи со споком 2 , спок 1 инициирует isakmp через провайдера blue, но так как на спок 2 default по прежнему через red нечего не работает"
Через IP-SLA мы можем точно отслеживать состояние провайдера RED, и менять шлюз на резервный при падении основного. Это будет третий способ как побороть проблему переключения. У меня именно так и работает
Хотя решение через VRF очень интересно.
RED /BLUE
Да, и ситуация, когда один из филиалов работает на резерве (BLUE): в этом случае общение филиала с другими идет через центральные роутеры, где через EIGRP контактируют два облака RED и BLUE
(Тема не указана)
ip-sla
На каждом споке все правильно есть sla и floating route. На спок1 провайдер red упал,default роут переключился на blue, а на втором споке по прежнему default red. И если у тебя работает то только через hub и то если сессию начнет устанавливать спок2, а если спок1 то вообще нечего не поднимется
ip-sla
Почему на спок1 ничего не поднимется? Маршруты сделаны на динамике EIGRP. Если умер основной провайдер, то маршруты через RED умрут через 15с (Hold). Далее маршруты пойдут только через резервный туннель blue. Если хочешь могу сделать эксперимент. только подробно опиши откуда и куда протестить пакеты.
Я лично обнаружил другую проблему: Изначально я вообще не планировал использовать IP SLA, и в филиале прописать два разных IP центра через разные статические маршруты. Но получилась следующая беда - если умирал основной, то по резервному оставался только статический на HUB, а вот связь до филиалов пыталась идти напрямую и умирала, а т.к. до белых IP филиалов маршрутов не было, то реально доступен был лишь центр. В итоге пока единственным рабочим решением стало смена дефолта через IP SLA.
Очень бы хотелось отказаться от смены дефолта, поскольку от этого зависит и провайдер для интернета юзеров, - а в идеале бы юзеров пустить по одному ISP, а туннели по другому.
Решает ли эту проблему использование vrf-lite?
Читайте также: