четверг, 19 декабря 2013 г.

ASR1K и BGP

На маршрутизаторах ASR1K примерно половина физической памяти отдается под ядро линукса, половина отводится под демон IOSd. Память рспределяется при загрузке и не может быть изменена. Согласно документу http://www.cisco.com/en/US/prod/collateral/routers/ps9343/data_sheet_c78-441072.html 4 гигов памяти на маршрутизаторах этой серии хватает для 500 000 маршрутов, т.е. примерно 1 BGP Full View. На самом деле при количестве маршрутов примерно равном 500К (1 Full View) остается 5-10 Мб свободной памяти, что почти гарантированно приводит к падению маршрутизатора в течение суток (чаще с выносом CEF - %FIB-2-FIBDOWN: CEF has been disabled due to a low memory condition. It can be re-enabled by configuring "ip cef [distributed]").

ASR#sh proc memory sorted holding
Processor Pool Total: 1141147824 Used: 1130455704 Free:   10692120
 lsmpi_io Pool Total:    6295128 Used:    6294296 Free:        832

 PID TTY  Allocated      Freed    Holding    Getbufs    Retbufs Process
 455   0 2277706752  981777672  572549920          0          0 BGP Router


ASR#sh ip bgp su
BGP router identifier 10.20.30.20, local AS number 4444
BGP table version is 2042851, main routing table version 2042851
484174 network entries using 120075152 bytes of memory
484175 path entries using 58101000 bytes of memory
79934/79930 BGP path/bestpath attribute entries using 19184160 bytes of memory
73011 BGP AS-PATH entries using 3216732 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 200577044 total bytes of memory
Dampening enabled. 0 history paths, 0 dampened paths
BGP activity 2100382/1616208 prefixes, 2103667/1619492 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.20.30.40   4        4444   216910    1934  2042851    0    0 1d05h      484174


Таким образом, для поддержания хотя бы 1 full view желательно иметь не менее 8 Gb памяти, 2 и более - 16 Gb.

понедельник, 16 декабря 2013 г.

Проблема получения IP адреса с DHCP Server Cisco ASA клиентами Apple

При организации DHCP сервера на Cisco ASA Cisco Adaptive Security Appliance Software Version 9.1(2) клиенты Apple не получают IP адреса. Это баг https://tools.cisco.com/bugsearch/bug/CSCuh79288. Лечится посредством команды "dhcprelay timeout 60" или даунгрейдом софта до 9.1.(1). Подобные трудности были замечены при использовании IP телефонов D-Link. Вероятно, лечится так же, проверить не было возможности.

пятница, 12 июля 2013 г.

Доступ к ASDM

При установке новой ASA  при  попытке доступа к ADSM по адресу https://asa/admin получаем ошибку типа:

Веб-страница по адресу https://10.50.18.201/admin, возможно, временно недоступна или постоянно перемещена по новому адресу.
Ошибка 113 (net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH): Неизвестная ошибка.

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

При попытке их конфигурации на ASA получаем:

ASA(config)# ssl encryption aes256-sha1 aes128-sha1 3des-sha1 
The 3DES/AES algorithms require a Encryption-3DES-AES activation key.

Видим, что не хватает лицензии:

ASA-1# sh version

Cisco Adaptive Security Appliance Software Version 9.1(1)
Device Manager Version 7.1(3)

........

Licensed features for this platform:
Maximum Physical Interfaces       : Unlimited      perpetual
Maximum VLANs                     : 300            perpetual
Inside Hosts                      : Unlimited      perpetual
Failover                          : Active/Active  perpetual
Encryption-DES                    : Enabled        perpetual
Encryption-3DES-AES               : Disabled       perpetual
Security Contexts                 : 2              perpetual
GTP/GPRS                          : Disabled       perpetual

Лицензию генерим здесь

Используем SN из show version (! а не из show inventory!)

Активируем лицензию:
ASA(config)# activation-key xxxx xxxx xxxx xxxx xxxxx

Включаем шифрование:
ASA(config)# ssl encryption aes256-sha1 aes128-sha1 3des-sha1

Если лицензия была сгенерирована на chasiss SN, получим:
ASA(config)# activation-key activation-key xxxx xxxx xxxx xxxx xxxx
Validating activation key. This may take a few minutes...
not supported yet.

среда, 26 июня 2013 г.

Операционная система коммутаторов HP Procurve

Не секрет, что после поглощения компанией HP компании 3Com коммутаторы последней начали выпускаться под лейблом HP, но(!) операционная система там оcталась по-прежнему Comware, а не была переделана на ProVision, которая используется в "родной" линейке HP. Некоторое время назад  указания на используемую операционную систему имелись в  описании  линеек на сайте HP Procurve. Однако в последнее время все чаще приходится только догадываться, что там внутри, в свзяи с чем полезно знать вот что:.

"Коммутаторы на основе ОС ProVision, как правило, имеют код продукта JXXXXY (где ХХХХ - арабские цифры). Это серии 25ХХ, 26ХХ, 28ХХ, 29ХХ, 38ХХ и др.

Коммутаторы на основе Comware (пришедшие из 3Com/H3C), как правило имеют код продукта JYXXXZ (где Y- латинская буква, ХХХ - арабские цифры). Это серии 3100, 3600, 5120, 5500, 5800 и др."


среда, 7 ноября 2012 г.

Aruba WiFi controller 650 Password Recovery

Процедура сброса пароля на WiFi контроллере Aruba 650:
1. подключиться консолью
2. Ввести в качестве имени пользователя"password", в качестве пароля "forgetme!"
3. Войти в режим enable, используя в качестве пароля "enable".
4. Войти в режим конфигурации с помощью команды "configure terminal"
5. Задать новый парольс помощью команды "mgmt-user admin root"
6. Перелогиниться, используя новый пароль
7. В режиме конфигурации ввести команду "enable secret", чтобы задать enable пароль.

Пример:
  User: password
Password: forgetme!
(aruba) >enable
Password: enable
(aruba) #configure terminal
Enter Configuration commands, one per line. End with CNTL/Z
(aruba) (config) #mgmt-user admin root
Password:
Re-Type password:
(aruba) (config) #exit
(aruba) #exit
(aruba) >exit

User: admin
Password:
(aruba) >enable
Password: enable
(aruba) #configure terminal
Enter Configuration commands, one per line. End with CNTL/Z
(aruba) (config) #enable secret
Password:
Re-Type password:
(aruba) (config) #write memory

понедельник, 21 мая 2012 г.

Etherchannel между Cisсo и Procurve



Cisco (Po1) - HP (Trk1) 

При объединении Cisco и HP  в Etherchannel обнаружилась неприятная вещь - при любом изменении количества активных волокон в канале на 1-2 секунды пропадает связь. Было обращение в TAC, где наличие проблемы подтвердили, однако решить ее быстро не смогли. Примерно через сутки активных экспериментов мне удалось подобрать такие настройки оборудования с обеих сторон, которые  исключили потери пакетов по крайне мере при добавлении линка и свели к ожидаемому  потери при падении одного из линков.
Итак, для минимизации потерь пакетов при падении/восстановлении физических линков, входящих в состав Etherchannel, необходимо выполнить следующие настройки:

1. Настроить на HP-Access Static LACP:
HP(config)# trunk 51-52 Trk1 LACP 
2. Настроить на Cisco LACP passive:
Cisco(config)#interface range Gi1/1,Gi1/2 
Cisco(config-if-range)#channel-group 1 mode passive

3. Для 6500 Cisco можно еще убедиться в том, что выбран Adaptive Hashing Method

Cisco(config)# show etherchannel <N> summary Flags: D - down P - bundled in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 U - in use N - not in use, no aggregation f - failed to allocate aggregator M - not in use, no aggregation due to minimum links not met m - not in use, port not aggregated due to minimum links not met u - unsuitable for bundling d - default port w - waiting to be aggregated Number of channel-groups in use: 5 Number of aggregators: 5 Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 1 Po1(RU) - Gi1/1(P) Gi1/2(P) Last applied Hash Distribution Algorithm: Adaptive 

Если поставлен метод Fixed, поменять на Adaptive
Cisco(config)# port-channel hash-distribution adaptive

Такие настройки позволят минимизировать потери пакетов при пропадании физического линка из состава Etherchannel и полностью избавиться от этого явления при восстановлении линка.

вторник, 27 марта 2012 г.

Объединение LAN через Inetnet с помощью L2TPv3.

Задача:
 Объединить на втором уровне VLAN300 центрального офиса и филиала посредством Internet.


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




Конфигурация на HQ

Конфигурация на Branch

l2tp-class L2TP.Class
  digest secret 0 cisco hash SHA1
 

pseudowire-class PWClass
  encapsulation l2tpv3

  protocol l2tpv3 L2TP.Class
  ip local interface FastEthernet0/1
 

interface FastEthernet0/0.300
 encapsulation dot1Q 300
 xconnect 5.5.5.1 1000 pw-class PWClass
 

interface FastEthernet0/1
 ip address 3.3.3.1 255.255.255.252
l2tp-class L2TP.Class
  digest secret 0 cisco hash SHA1
 

pseudowire-class PWCLass
  encapsulation l2tpv3

  protocol l2tpv3 L2TP.Class
  ip local interface FastEthernet0/1
 

interface FastEthernet0/0.300
  encapsulation dot1Q 300
  xconnect 3.3.3.1 1000 pw-class PWCLass
 

interface FastEthernet0/1
  ip address 5.5.5.1 255.255.255.252

Важно!
  1. Должен быть включен CEF
  2. Если есть необходимость использовать разные VLAN'ы на концах туннеля, нужно использовать VLAN ID Rewrite feature.

Как это работает:

L2TPv3(protocol 115) используется для построения канала pseudowire.  Пакеты, прибывающие на интерфейс FastEthernet0/0.300 любого маршрутизатора вместе с заголовками 2-го уровня перенаправляются в L2TPv3 туннель. l2tp-class L2TP.Class   - определяет параметры канала pseudowire такие, как аутентификация точек по паролю, интервалы hello-пакетов и т.п.
 digest secretпароль хэшинга

Troubleshooting:
R# show l2tun tunnel state
R# show l2tun session 

вторник, 14 февраля 2012 г.

Настройка мониторинга состояния интерфейсов Cisco при помощи PRTG

Для мониторинга состояния интерфейсов (в том числе виртуальных) на маршрутизаторах Cisco ISR с помощью PRTG можно воспользоваться штатными средствами PRTG.
Для этого можно использовать SNMP сенсор SNMP Library:

Далее выбираем Cisco-interfaces.oidlib

Затем выбираем нужный интерфейс с параметром if oper status. Для определения номера нужного интерфейса на маршрутизаторе удобно использовать команды:
R# sh int desc
R# sh snmp mib ifmib ifindex


Интерфейсы предварительно должны быть закреплены командой
R(config)# snmp-server ifindex persist 

После создания сенсора переходим в редактирование настроек каналов. Выбираем канал if oper status и определяем для него лимитное значение. Значения этого параметра выше указанного лимита будут трактоваться PRTG как переход сенсора в состояние DOWN. Поскольку, значение этого параметра, равное 1 означает состояние protocol is up, а 2 = protoсol is down, поставим верхнее значение равным 1:
Теперь, по желанию настраиваем Notifications -> Add State Trigger

четверг, 29 декабря 2011 г.

BGP и BFD на Cisco

Bidirectional Forwarding Detection (BFD) - протокол, позволяющий быстро обнаруживать проблемы связности маршрутизаторов на IP уровне и тем самым обеспечивающий быструю сходимость протоколов маршрутизации.
BFD - двусторонний протокол, оба  маршрутизатора генерируют BFD пакеты, а также отвечают на BFD пакеты посланные соседом. Протокол BFD практически не влияет на производительность CPU, поэтому интервал между BFD пакетами может быть сокращен до 50 мс, что обеспечивает быструю сходимость.
BFD пакеты инкапсулируются в unicast UDP. BFD payload control пакеты используют в качестве  destination port 3784 и в качестве  source port 49152.
BFD Echo пакеты используют destination port 3785 и source port 3785.

BFD может работать в 2-х режимах:
1.  BFD Async  - в этом режиме маршрутизаторы обмениваются только control пакетами.
2.  BFD Echo - в этом режиме маршрутизаторы обмениваются помимо control еще и  echo пакетами. Echo пакеты отличаются от control тем, что имеют адрес назначения равный адресу источника. Попадая на соседнюю систему они проходят весь обычный forwarding path, таким образом обеспечивая более полное тестирование работоспособности системы. По умолчанию на Cisco маршрутизаторах BFD Echo mode включен (отключается командой no bfd echo на интерфейсе). При использовании echo mode необходимо указывать no ip redirects на интерфейсе во избежание перегрузки CPU. Частота control пакетов может быть в этом режиме снижена (команда bfd slow-timers в режиме глобальной конфигурации позволяет настраивать интервал генерации control пакетов).



Рассмотрим на примере:


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

Однако, ситуация меняется, если между маршрутизаторами появляется коммутатор:


В этом случае падение интерфейса на маршрутизаторе ISP никак не будет обнаружено маршрутизатором CE1. Удаление недействительного маршрута полностью зависит от таймеров используемого протокола маршрутизации (до 3 минут у BGP).

В этой ситуации спасет использование BFD. Между маршрутизаторами устанавливаем двустороннюю BFD сессию:

 Настраивается на интерфейсах обоих маршрутизаторов :


interface FastEthernet0/1
 bfd interval N1 min_rx N2 multiplier  interval-multiplier
 no ip redirects  
N1 -  интервал генерации control пакетов (в миллисекундах), от 50 до 999
N2 - минимальный интервал между входящими control пакетами, от 50 до 999
 interval-multiplier - количество последовательно пакетов, которые BFD может пропустить прежде чем информировать Layer 3 о проблеме.

После чего  привязываем используемый нами протокол маршрутизации (в данном случае BGP) к состоянию BFD сессии.


router bgp 200
 neighbor 3.3.3.2 fall-over bfd

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


В результате при обнаружении падения BFD сессии (несколько сотен миллисекунд), маршрутизатор разрывает BGP сессию и оперативно удаляет  недействительные маршруты из таблицы маршрутизации.

Пример 1. Работа без BFD

Роняем интерфейс F0/1 на ISP.

ISP1#sh logg
000068: Dec 29 18:36:52.068 Moscow: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down

CE1#sh logg
*Dec 29 18:39:33.453 Moscow: %BGP-5-ADJCHANGE: neighbor 3.3.3.2 Down BGP Notification sent
*Dec 29 18:39:33.453 Moscow: %BGP-3-NOTIFICATION: sent to neighbor 3.3.3.2 4/0 (hold time expired) 0 bytes
*Dec 29 18:39:33.453 Moscow: %BGP_SESSION-5-ADJCHANGE: neighbor 3.3.3.2 IPv4 Unicast topology base removed from session  BGP Notification sent

Разница между падением интерфейса на ISP  и удалением недействительных маршрутов на CE1,  2 минуты 41 секунда

Пример 2. Работа c BFD

На обоих маршрутизаторах выполнены команды
interface FastEthernet0/1
 bfd interval 50 min_rx 50 multiplier 4


Роняем интерфейс F0/1 на ISP.

ISP1#sh logg
000064: Dec 29 18:25:45.295 Moscow: %BGP-5-ADJCHANGE: neighbor 3.3.3.1 Down BFD adjacency down
000065: Dec 29 18:25:52.123 Moscow: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down

CE1#sh logg
*Dec 29 18:25:45.497 Moscow: %BGP-5-ADJCHANGE: neighbor 3.3.3.2 Down BFD adjacency down
*Dec 29 18:25:45.497 Moscow: %BGP_SESSION-5-ADJCHANGE: neighbor 3.3.3.2 IPv4 Unicast topology base removed from session  BFD adjacency down


Разница между падением интерфейса на ISP  и удалением недействительных маршрутов на CE1, как и должно быть согласно заданным параметрам, порядка 200 миллисекунд

Стандартная реализация ВFD в Cisco не позволяет поддерживать сессии с промежуточными IP узлами между соседями:


 Соответственно, не получится поднять BFD сессию для multihop eBGD или iBGP с использованием Loopback'ов.
Однако с версии 15.1(3)S появилась фича multihop BFD, позволяющая обойти это ограничение:



Troubleshooting:
show bfd neighbors
show bfd neighbors details

понедельник, 26 декабря 2011 г.

Multihomed BGP

Задача:

Имеются собственные PI адреса (1.1.1.0/24), собственная AS (AS100) и подключение к 2-м провайдерам.  Один провайдер основной(ISP1), второй резервный(ISP2). Необходимо обеспечить резервирование выхода в интернет на уровне железа.

Ограничения:

Одна железка(CE1) держит BGP full view, другая(CE2) нет. Слабая железка CE2 имеет только 2 интерфейса FastEthernet.





Решение:

Поднимаем eBGP сессии с провайдерами и iBGP между своими маршрутизаторами. Сильный маршрутизатор CE1 получает Full View от основного провайдера, слабый CE2 только дефолт от запасного. Оба маршрутизатора анонсируют свою сеть (1.1.1.0/24) и модифицируют атрибуты так, чтобы  обратный трафик с большей вероятностью возвращался через основного провайдера.  Между собой маршрутизаторы устанавливают iBGP сессию, CE2 отдает дефолтный маршрут, полученный по eBGP от ISP2, на сильный маршрутизатор CE1. CE1 не отдает на CE2 ничего. Сеанс устанавливаем на реальные адреса, т.к. путь друг до друга у CE1 и CE2 один. Со стороны локальной сети между CE1 и CE2 поднят HSRP с виртуальным адресом 1.1.1.1/24 (на схеме не обозначено). Приоритет HSRP выставлен так, что CE1 является Active.


Настройка

CE1:

interface FastEthernet0/0
 ip address 1.1.1.3 255.255.255.0

 no ip redirects - Cisco рекомендует выполнять эту команду при использовании BFD, т.к. в противном случае будет грузиться CPU
 standby 4 ip 1.1.1.1
- Конфигурируем виртуальный HSRP адрес
 standby 4 timers 1 3
 standby 4 priority 200
- Делаем этот маршрутизатор Active
 standby 4 preempt
 bfd interval 50 min_rx 50 multiplier 4
- поднимаем BFD
end


 router bgp 100
  bgp log-neighbor-changes
  bgp dampening
  network 1.1.1.0 mask 255.255.255.255

  
neighbor 1.1.1.2 remote-as 100 - формируем iBGP сессию
  neighbor 1.1.1.2 next-hop-self 
- при пересылке маршрутов на 1.1.1.2 менять значение next-hop на свой адрес. По умолчанию для iBGP сессий этого не происходит.
  neighbor 1.1.1.2 soft-reconfiguration inbound - сохраняет все полученные от соседа маршруты в памяти, что позволяет применять различные фильтры на входящие апдейты от соседа без переустановки bgp сессии, а также видеть результаты крайне полезной команды show ip bgp neighbors Х.Х.Х.Х received-routes
  neighbor 1.1.1.2 prefix-list DEFAULT_ROUTE in - на вход от CE2 разрешаем только дефолт
  neighbor 1.1.1.2 prefix-list NOTHING out
- и ничего не отправляем на CE2
  neighbor 3.3.3.2 remote-as 300 -
формируем eBGP сессию
  neighbor 3.3.3.2 fall-over bfd
- функция обеспечивает быструю сходимость протокола BGP. Необходимо настраивать на обоих маршрутизаторах, участвующих в сессии. Устанавливается двусторонняя UDP сессия. Поскольку нагрузку на CPU почти не дает,  интервалы обмена сообщениями могут быть очень маленькими, от 50 мс. Таким образом, при пропадании доступности соседнего IP hop BGP сессия рвется сразу, не выдерживая таймаута в 3 минуты.
 
Для настройки BFD сессии между маршрутизаторами, находящимися на расстоянии через 1 и более IP узлов, например, multihop eBGP или iBGP с промежуточным маршрутизатором между соседями, требуется multihop BGP feature, доступная только с версии 15.1(3)S.
  neighbor 3.3.3.2 soft-reconfiguration inbound -
сохраняет все полученные от соседа маршруты в памяти, что позволяет применять различные фильтры на входящие апдейты от соседа, а также видеть результаты крайне полезной команды show ip bgp neighbors Х.Х.Х.Х received-routes
  neighbor 3.3.3.2 prefix-list OUR_PI out
- анонсируем только свои PI адреса, дабы не превратиться в транзитную систему.
  no auto-summary



ip prefix-list OUR_PI seq 5 permit 1.1.1.0/24
ip prefix-list DEFAULT_ROUTE seq 5 permit 0.0.0.0/0
ip prefix-list NOTHING seq 5 deny 0.0.0.0/0

CE2:
Практически все то же самое

interface FastEthernet0/0
 ip address 1.1.1.2 255.255.255.0
 no ip redirects
 bfd interval 50 min_rx 50 multiplier 4
 standby 4 ip 1.1.1.1
 standby 4 timers msec 500 1
 standby 4 preempt

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 bgp dampening
 network 1.1.1.0 mask 255.255.255.0
 neighbor 1.1.1.3 remote-as 100
 neighbor 1.1.1.3 next-hop-self
 neighbor 1.1.1.3 soft-reconfiguration inbound
 neighbor 1.1.1.3 prefix-list NOTHING in
- ничего не берем с CE1
 neighbor 1.1.1.3 prefix-list DEFAULT_ROUTE out
- отправляем на CE1 только дефолт
 neighbor 2.2.2.2 remote-as 200
 neighbor 2.2.2.2 fall-over bfd
 neighbor 2.2.2.2 soft-reconfiguration inbound
 neighbor 2.2.2.2 prefix-list DEFAULT_ROUTE in
- принимаем от ISP2 только дефолт
 neighbor 2.2.2.2 prefix-list OUR_PI out
- отправляем только свои PI адреса, чтобы избежать транзита
 neighbor 2.2.2.2 route-map AddASnumbers out
- добавляем дополнительные экземпляры номера своей AS для того, чтобы сделать этот маршрут менее предпочтительным для обратного трафика
 no auto-summary

ip prefix-list OUR_PI seq 5 permit 1.1.1.0/24
ip prefix-list DEFAULT_ROUTE seq 5 permit 0.0.0.0/0
ip prefix-list NOTHING seq 5 deny 0.0.0.0/0

route-map AddASnumbers permit 10
 set as-path prepend 100 100 100 100



Как это работает:

В тестовых целях на ISP1 подняты Loopback 1-3 (которые анонсируются по BGP) для имитации Full View,   Loopback0 (который не анонсируется) для тестирования маршрута по умолчанию. На ISP2 поднят Loopback0(анонсируется). Кроме того, на ISP прописан статикой маршрут до 99.99.99.99. Тестовая рабочая станция в AS100 имеет адрес 1.1.1.112.



1. Нормальный режим.

Исходящие пакеты
В штатном режиме  исходящие пакеты будут всегда попадать на CE1 (HSRP Active). При наличии маршрута в full view, они уйдут на ISP1, иначе уйдут через default route, полученный с CE2,  на CE2 и оттуда на ISP2.

Проверка:
 Основной трафик c хоста в локальной сети AS100

Tracing the route to  66.66.66.66 
  1    <1 мс    <1 мс    <1 мс  1.1.1.3
  2    <1 мс    <1 мс    <1 мс  66.66.66.66

Проверка дефолта c хоста в локальной сети AS100
Tracing the route to  99.99.99.99
  1    <1 мс    <1 мс    <1 мс  1.1.1.3
  2    <1 мс    <1 мс    <1 мс  1.1.1.2
  3    <1 мс    <1 мс    <1 мс  2.2.2.2
  4    <1 мс    <1 мс    <1 мс  99.99.99.99


Входящие пакеты
 Большая часть трафика возвращается через основной канал ISP, поскольку CE2 при анонсе маршрута  дополнительно вставляет в атрибут as-path несколько  номеров своей AS, таким образом влияя на принятие решения о выборе лучшего маршрута маршрутизаторами за пределами своей AS (AS100). Однако, это влияние не может быть абсолютным и администраторы других AS могут применять политику маршрутизации, не учитывающую длину AS PATH, таким образом некоторая часть трафика может возвращаться через запасного провайдера ISP2.



Проверка:
Большинство пакетов с маршрутизатора ISP2

Tracing the route to 1.1.1.112
  1 4.4.4.1 0 msec 4 msec 0 msec
  2 3.3.3.1 0 msec 0 msec 0 msec
  3 1.1.1.112 [AS 100] 0 msec 0 msec 0 msec


2. Падение интерфейса F0/0 маршрутизатора CE1 

Исходящие пакеты
Виртуальный адрес HSRP будет перехвачен маршрутизатором CE2 и затем уйдут по дефолту на ISP2.

Проверка:
C хоста в локальной сети AS100 
Tracing the route to 66.66.66.66
  1    <1 мс    <1 мс    <1 мс  1.1.1.2
  2    <1 мс    <1 мс    <1 мс  2.2.2.2
  3    <1 мс    <1 мс    <1 мс  66.66.66.66

Входящие пакеты

Проверка:
С маршрутизатора ISP1 
ISP1#traceroute 1.1.1.112
  1 4.4.4.2 0 msec 0 msec 0 msec
  2 2.2.2.1 4 msec 0 msec 0 msec
  3 1.1.1.112 [AS 100] 4 msec 0 msec 0 msec


3.Падение F0/1  на CE1 или F0/1 на ISP1

Исходящие пакеты
При падении F0/1  на CE1 или F0/1 на ISP1  пакеты приходят сначала на CE1, потом с него на CE2, потом на ISP2. Для ускорения переключения CE1 на дефолтный маршрут между ISP1 и CE1 поднята BFD сессия и BGP настроен реагировать на ее состояние.


Проверка:
C хоста в локальной сети AS100 
Tracing the route to  66.66.66.66
  1    <1 мс    <1 мс    <1 мс  1.1.1.3
  2    <1 мс    <1 мс    <1 мс  1.1.1.2
  3     1 ms    <1 мс    <1 мс  2.2.2.2
  4    <1 мс    <1 мс    <1 мс  66.66.66.66






Входящие пакеты

Проверка: 
С маршрутизатора ISP1   
Tracing the route to 1.1.1.112
  1 4.4.4.2 0 msec 4 msec 0 msec
  2 2.2.2.1 0 msec 4 msec 0 msec
  3 1.1.1.112 [AS 100] 0 msec 4 msec 0 msec


4. Падение F0/0, F9/1 на CE2 или F0/1 на ISP2.

Исходящие пакеты
При падении любого из интерфейсов CE2 или F0/1 на ISP2 начинают теряться только те пакеты, маршрут к которым отсутствует в Full View на CE1.

Проверка:
Основные маршруты с хоста в локальной сети AS100 
Tracing the route to  66.66.66.66
  1    <1 мс    <1 мс    <1 мс  1.1.1.3
  2    <1 мс    <1 мс    <1 мс  66.66.66.66


Маршрут по умолчанию с хоста в локальной сети AS100 
Tracing the route to  99.99.99.99
  1    <1 мс    <1 мс    <1 мс  1.1.1.3
  2  1.1.1.3  сообщает: Заданный узел недоступен.

 

Входящие пакеты


Проверка:
С маршрутизатора ISP2  

Tracing the route to 1.1.1.112
  1 4.4.4.1 0 msec 0 msec 4 msec
  2 3.3.3.1 0 msec 0 msec 0 msec
  3 1.1.1.112 [AS 100] 0 msec 4 msec 0 msec



Troubleshooting

1. Быстро посмотреть настройку BGP  в конфиге:
R#show running-config | section bgp



2. Посмотреть состояние BGP сессий:
R#show ip bgp summary

3. Посмотреть на список BGP маршрутов, получаемых от конкретного соседа:
R#show ip bgp neighbors 4.4.4.1 received-routes

4. Посмотреть список маршрутов от  конкретного соседа после применения всех фильтров:
R#show ip bgp neighbors 4.4.4.1 routes

5. Посмотреть список маршрутов, анонсируемых конкретному соседу:
R#show ip bgp neighbors 4.4.4.1 advertised-routes

6. Посмотреть таблицу BGP маршрутов на маршрутизаторе
R#show  ip bgp

7. Посмотреть таблицу маршрутизации
R#show ip route


8. Посмотреть состояние HSRP
R#show standby

9. Посмотреть состояние BFP
R#show bfd neighbors




среда, 30 ноября 2011 г.

G.703, E1, pri-group, ds0-group и channel-group

За помощь в подготовке и рецензировании материала 
выражаю благодарность Сергею Бачерикову

Разберем  настройку на Cisco ISR


1.G.703 - это стандарт ITU-T, описывающий электрические характеристики передачи информации на скорости 2048 Кбит/с.
Физически чаще всего реализуется на витой паре (разъем RJ-48, передача по 4-5, прием по 1-2, но бывают варианты). С таким потоком могут работать только интерфейсные карты типа VWIC3-1MFT-G703.   Но не карты типа VWIC2-2MFT-T1/E1. Неструктурированный G.703 может использовать всю полосу пропускания для передачи данных, поскольку не теряет 64 Кбит/с для синхронизации оконечного оборудования, в отличие от E1.
G.703 в разрезе (условно):




2. Разбив G.703 на 32 таймслота (TS0-TS31) и выделив один таймслот для синхронизации оконечного оборудования (TS0), получаем цифровой поток E1 (в случае T1 поток разбивается на 24 таймслота). Имеем 31 слот DS0 (64 Кбит/с), доступных пользователю ( 64 Кбит/с*31 = 1984 Кбит/с ) и 1 слот под синхронизацию. С таким потоком умеют работать все виды карт - и *-G703 и *-T1/E1.
E1 в разрезе (условно):





3.Теперь эти цифровые слоты можно группировать и использовать по своему усмотрению:
 - pri-group - для телефонии E1 PRI 
 - ds0-group - для телефонии с CAS сигнализацией (например, R2)
 - channel-group - для данных
 Все три вида могут быть сконфигурированы на одном физическом интерфейсе.

  3.1 pri-group
   Для конфигурирования ISDN PRI необходимо выполнить команду    pri-group timeslots N1-N2. 
Например, команда   
R(config)# controller e1 0/3/0
R(config-controller)# pri-group timeslots 1-16  

выделяет таймслоты  1-16 под телефонию. При этом в ISDN PRI таймслот 16 по умолчанию всегда используется под сигнализацию и автоматически создается интерфейс типа Serial0/3/0:15. Поскольку интерфейсы  Serial нумеруются так же, как и  таймслоты, с нуля,  Serial0/3/0:15 соответствует TS16.


E1 с выделенной PRI-group (условно): 





 3.2 ds0-group
  Используется для звонков с CAS сигнализацией и настраивается командой
  ds0-group N timeslots range type type
  Могут быть доступны следующие виды сигнализаций:
  e&m-delay-dial           E & M Delay Dial
  e&m-fgd                     E & M Type II FGD
  e&m-immediate-start   E & M Immediate Start
  e&m-lmr                      E & M land mobil radio
  e&m-melcas-delay       MEL CAS (CEPT) E & M Delay Start
  e&m-melcas-immed     MEL CAS (CEPT) E & M Immediate Start
  e&m-melcas-wink        MEL CAS (CEPT) E & M Wink Start
  e&m-wink-start            E & M Wink Start
  ext-sig                          External Signaling
  fxo-ground-start           FXO Ground Start
  fxo-loop-start               FXO Loop Start
  fxo-melcas                   MEL CAS (Mercury) FXO
  fxs-ground-start           FXS Ground Start
  fxs-loop-start               FXS Loop Start
  fxs-melcas                   MEL CAS (Mercury) FXS
  none                            Null Signalling for External Call Control
  r2-analog                     R2 ITU Q411
  r2-digital                      R2 ITU Q421
  r2-pulse                       R2 ITU Supplement 7

Например, 
R(config)# controller e1 0/3/0
R(config-controller)# ds0-group 1 timeslots 17-23 type r2-analog
E1 с выделенной PRI-group и ds0-group (условно): 






 3.3 channel-group
Используется для передачи данных по E1 и настраивается командой channel-group N timeslot N1-N2.
Например:
R(config)# controller e1 0/3/0
R(config-controller)# channel-group 1 timeslot 24-31
E1 с выделенной PRI-group, ds0-group и channel-group (условно): 



четверг, 27 октября 2011 г.

DHCP сервер на маршрутизаторе Cisco для телефонов AVAYA

Задача:

Имеется небольшая сеть филиала с некоторым количеством IP телефонов. Необходимо  динамически раздавать адреса компьютерам и телефонам. Кроме того, телефоны необходимо перемещать в голосовой  VLAN и сообщать им дополнительные настройки путем загрузки файла конфигурации с TFTP сервера.


DATA VLAN - 1, native
Voice VLAN - 2

IP конфигурация:

DATA - 10.1.1.0/24
VOICE - 172.16.1.0/24

Решение:

Реализуем DHCP сервер на маршрутизаторе Cisco. 
Процесс загрузки телефонов при этом будет выглядеть так:
1. Телефон получает DHCP адрес в native VLAN (DATA) и опцию 191. Эта опция указывает телефону его Voice VLAN.
2. Телефон меняет свой VLAN на Voice VLAN и делает новый DHCP запрос, уже тегируя пакеты.
3. Телефон получает новый IP адрес уже из Voice VLAN. Кроме того, телефон получает дополнительно опцию 224, указывающую на TFTP сервер с файлом настроек.
3. Телефон загружает файл настроек с TFTP сервера и подключается к телефонной станции.


Настройки Cisco:

ip dhcp excluded-address 10.1.1.1
ip dhcp excluded-address 172.16.1.1
!
ip dhcp pool DHCP_POOL
   network 10.1.1.0 255.255.255.0
   default-router 10.1.1.1
   option 191 ascii VLAN-A:2.
   lease 14
!
ip dhcp pool DHCP_PHONE_POOL
   network 172.16.1.0 255.255.255.0
   default-router 172.16.1.1
   option 224 ascii Nortel-i2004-B,prov=Х.Х.Х.Х; - адрес Вашего TFTP сервера
   lease 14
!
interface FastEthernet0/0
 ip address 10.1.1.1 255.255.255.0
 duplex auto
 speed auto
 no keepalive
!
interface FastEthernet0/0.2
 encapsulation dot1Q 2
 ip address 172.16.1.1 255.255.255.0
!
interface FastEthernet0/1
 ip address 200.200.200.201 255.255.255.252
 duplex auto
 speed auto

Настройки Procurve:

hostname "ProCurve Switch 2610-48-PWR"
vlan 1
   name "DEFAULT_VLAN"
   untagged 1-52
   exit
vlan 2
   name "PHONE"
   tagged 1-52
   voice 
   exit

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

Ссылки:
AVAYA IP Telephony Deployment Technical Configuration Guide