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

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

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 (условно): 

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

SVTI - DVTI

Дано: большое число филиалов, имеющих доступ к центральному офису по VTI.
Задача: упростить конфигурацию центрально маршрутизатора.
Решение: применяем Dynamic VTI на центральном маршрутизаторе. На филиалах остается Static VTI.

DVTI на HE:

crypto keyring KEYRING
  pre-shared-key address 0.0.0.0 key 11111 - Адрес Brach допустим любой, ключ указываем. Можно разным Branch разные ключи указать.
!
crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 2
crypto isakmp profile DVTI
   keyring KEYRING
   match identity address Branch1-IP-Address - Адрес Branch1.    Можно не ограничивать адреса,указав match identity 0.0.0.0
   .

   .

   .

   match identity address BranchN-IP-Address
   keepalive 10 retry 2 - Обязательно
   virtual-template 1

!
crypto ipsec transform-set TS ah-sha-hmac esp-aes
!
crypto ipsec profile VTI
 set transform-set TS
!
interface Virtual-Template1 type tunnel
 ip unnumbered FastEthernet0/0  - На FE0/0 ставим no keepalive, если допустимо. Если нет, то в качестве источника IP адреса берем Loopback
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI
!

SVTI на BranchN:

interface Loopback0
 ip address 10.0.0.1 255.255.255.255
!
crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 2
!

crypto isakmp key 11111 address 1.1.1.1 - Адрес HE
crypto isakmp keepalive 10
!
crypto ipsec transform-set TS ah-sha-hmac esp-aes
!
crypto ipsec profile VTI
 set transform-set TS
!
interface Tunnel0
 description To HE
 ip unnumbered Loopback0 
 tunnel source FastEthernet0/1
 tunnel destination 1.1.1.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

Плюс не забываем про протокол маршрутизации. Для уменьшения нагрузки на маршрутизаторы и линии связи лучше использовать EIGRP. 

В данном случае EIGRP используется только между HE и филиальными маршрутизаторами, чтобы BranchN мог аннонсировать свои внутренние сети центральному узлу. Поэтому на физических интерфейсах EIGRP включаем, но ставим ставим passive.


EIGRP на HE:

router eigrp 100

 network 10.0.0.0 0.0.255.255
 passive-interface FastEthernet0/0
 passive-interface FastEthernet0/1
 no auto-summary 

interface Virtual-Template1 type tunnel 

 ip summary-address eigrp 100 10.0.0.0 255.0.0.0 


EIGRP на Branch1:

router eigrp 100

 passive-interface default
 no passive-interface Tunnel0

 network 10.0.0.0 0.0.255.255 

 no auto-summary 

 eigrp stub connected 

Важно! Оба конца туннеля должны быть ip unnumbered.


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

Virtual Tunnel Interface (VTI) Design Guide - этот дизайн гайд раньше был доступен на cisco.com. Теперь они его либо убрали совсем, либо  как-то хитро спрятали. Стало проще найти его в Интернете, чем на их сайте.
IPSec Direct Encapsulation Design Guide

LLQ на VTI

Cisco  не поддерживает настройку очередей на логических интерфейсах (например, VTI) напрямую.
При попытке повесить соответсующую service-policy на логический интерфейс получим подобную ошибку(иногда, впрочем политика не применяется совершенно молча):

R(config)#int tu0

R(config-if)#service-policy output LLQ-POLICY

Low Latency Queueing feature is not supported in user defined class of parent level policy

При необходимости настроить LLQ на логическом интерфейсе нужно применять вложенные политики, причем в родительской политике должен применяться шейпинг:

policy-map child 

 class voice 

 priority 512 

 class class-default
  fair-queue

policy-map parent

 class class-default 

 shape average 2000000

 service-policy child 

interface tunnel0 

 service-policy output parent

Ссылки:

Implementing Tunnels 

Мониторинг трафика на маршрутизаторе Cisco в реальном времени

Самым удобным способом  отслеживания трафика на интерфейсах маршрутизатора в реальном времени является  настройка Netflow. 

Справка из википедии:

  

NetFlow — сетевой протокол, предназначенный для учёта сетевого трафика, разработанный компанией Cisco Systems. Является фактическим промышленным стандартом и поддерживается не только оборудованием Cisco, но и многими другими устройствами (в частности, Juniper и Enterasys). Также существуют свободные реализации для UNIX-подобных систем.

Для сбора информации о трафике по протоколу NetFlow требуются следующие компоненты:

1. Сенсор. Собирает статистику по проходящему через него трафику. Обычно это L3-коммутатор или маршрутизатор, хотя можно использовать и отдельно стоящие сенсоры, получающие данные путем зеркалирования порта коммутатора.

2. Коллектор. Собирает получаемые от сенсора данные и помещает их в хранилище.

3. Анализатор. Анализирует собранные коллектором данные и формирует пригодные для чтения человеком отчёты (часто в виде графиков).

Маршрутизатор в данных терминах  будет сенсором Netflow, а без коллектора и анализатора можно обойтись, если нам не нужно хранить данные и  делать развесистые отчеты.

Настройка проста:

1. Обе команды можно выполнить или в глобальном режиме или в режиме конфигурации интерфейса.

  ip flow ingress - собирает статистику по входящему трафику

  ip flow egress  - собирает статистику по исходящему трафику

2. Настройка примитивного отчета в глобальном режиме.

  ip flow-top-talkers
   top 30
   sort-by bytes
   cache-timeout 30000

3. Настроим таймеры  в глобальном режиме:

   ip flow-cache timeout inactive 10
   ip flow-cache timeout active 5

После этого командами

show ip flow top-talkers

sh ip cache flow

можно увидеть наиболее активные хосты и типы трафика.

Если есть необходимость хранить историю загрузки и выводить красивые отчеты для начальства, можно воспользоваться  таким инструментом, как PRTG.

Аутентификация пользователей Cisco ASA через Microsoft Windows NPS.

Задача:

Аутентифицировать Remote IPSec VPN пользователей, терминирующихся на ASA, в домене Windows.

Решение:

Используем для этого Radius. В качестве Radius сервера настроим Microsoft Network Policy Server.

1. ASA получает запрос на установление туннеля от клиента.
2. ASA отсылает запрос на аутентификацию/авторизацию к Radius серверу, чьи функции выполняет NPS.
3. NPS делает запрос в AD.
4. AD отвечает NPS.
5. NPS посылает ответ ASA по Radius протоколу.
6. Устанавливается (или не устанавливается) IPSec туннель.


1. Настройка Cisco ASA.

1) Запустить ASDM, выбрать вкладку Configuration.
2) Выбрать секцию Remote Access VPN
3) Выбрать в меню AAA Setup -> AAA Server Groups
4) Выбрать Add рядом с секцией  AAA Server Groups
5) Выбрать имя группе, например NSP-RADIUS и не забыть указать протокол RADIUS
6) Оставить все остальные настройки по умолчанию и нажать OK.
7) Выбрать только что созданную Server Group.
8) Ниже в секции Servers in the Selected Group нажать Add
9) В поле Interface Name вырать интерфейс, через который ASA будет отсылать запросы на Radius Server.
10) В поле Server Name or IP Address ввести IP адрес нашего Radius сервера.
11) Придумать (и запомнить) пароль и ввести его в поле Server Secret Key. Его же вводим в поле Common Password.
12) Остальное по дефолту и нажать OK.



2. Настройка Microsoft Windows Network Policy Server


Установить Windows Server 2008, который будет нашим Radius сервером.
Добавить функцию Network Policy Server на установленный сервер.

 1) На Windows Server 2008 запустить Server Manager.
 2) Выбрать Roles и нажать правую клавишу мыши и выбрать Add Roles.
 3) На странице Before You Begin нажать Next.
 4) Выбрать роль Network Policy and Access Services role и нажать Next.
 5) Среди Role Service выбрать только Network Policy Server service и нажать Next.
 6) Нажать Install.

По окончании инсталляции регистрируем сервер. Для выполнения этой процедуры нужны права администратора домена.
 7) Выбираем Roles -> Network Policy ans Access Services -> NPS(Local) и нажимаем правую клавишу.
 8) В меню выбираем Register Server in Active Directory.
 9) Выбираем все по дефолту.

Создаем клиентскую запись для ASA.
 10) Выбираем NPS(Local) -> RADIUS Clients and Servers -> Radius Clients.
 11) По правой клавише выбираем New.
 12) Придумываем Friendly Name для нашей ASA. Например, “ASA” :)
 13) Вводим Address(IP or DNS).
 14) Вводим Server Secret Key, который мы указывали в шаге 11 при настройке ASA.
 15) Остальное оставляем по дефолту.

Создаем Connection Request Policy.
 16) Выбираем NPS(Local) -> Policies ->  Connection Request Policies.
 17) В правой половине окна выбираем политику по умолчанию, щелкаем правой клавишей и выбираем Disable.
 18) Встаем обратно на NPS(Local) -> Policies ->  Connection Request Policies и правой клавишей выбираем New.
 19) Выбираем осмысленное имя политики, например ASA.
 20) Оставляем в поле Type of Access значение Unspecified, кликаем Next.
 21) На странице Conditions щелкаем Add. Выбираем и указываем Client IPv4 Address.
 22) Щелкаем Next, на остальных страницах оставляем настройки по умолчанию.

Создаем Network Policy.
 23) По правыму щелчку мыши на  Network Policy выбрать  New.
 24) Дать осмысленный Policy Name. Оставить в поле Type of network access server значение Unspecified и нажать Next.
 25) Требуется определить хотя бы 1  условие в Conditions. Нжимаем Add.
 26) Добавим UsersGroup, чтобы обозначить, что данная политика применяется для соответствуюшей группы в  AD. Можно добавить Client IPv4 Address или любые другие условия. Нажать Next.
 27) В секции Access Permission оставим Access granted (в принципе этот параметр утрачивает влияние, если в шаге 30) мы определим атрибут Class. Но если хотим по-простому можно контролировать доступ этой кнопкой). Жмем Next.
 28) В качестве Authentication methods выбираем только Unencrypted authentication (PAP, SPAP). жмем Next.
 29) Для доступа по VPN выбираем NAS Port Type = Virtual(VPN). жмем Next.
 30) В Settings -> RADIUS Attributes -> Standard выбираем Service-Type = Framed, Framed-Protocol = PPP. По желанию, можно добавить Class с названием политики на ASA, которую надо применять к данному подключению. Жмем Next.
 31) Жмем Finish.

Перестартуем Network Policy Server service.

Проверяем RADIUS аутентификацию.

1) В ASDM выбираем Configuration -> Remote Access VPN -> AAA Setup -> AAA Server Groups
2) Выбираем только что созданную группу.
3) Внизу выбираем сервер и нажимаем справа кнопку Test.
4) Выбираем Authentication, вводим логин, пароль и убеждаемся, что все работает.



Ссылки:

RFC2865 - The RFC "Remote Authentication Dial In User Service (RADIUS)"

Многое взято отсюда

NAT и Multiple NAT Pools, трансляция с привязкой к интерфейсу.

При использовании NAT иногда возникает необходимость  использовать разные NAT pool’ы в зависимости от адреса назначения. Например, пакеты, адресованные в Интернет необходимо транслировать  в публичные адреса компании. А пакеты, уходящие через IPSec VTI  и адресованные партнерам, имеющим перекрывающееся адресное пространство, надо транслировать  в ранее согласованные адреса.

Схема:

И головной офис, и офис партнера используют сеть 10.0.0.0/8 для собственных нужд. У головной компании есть собственные публичные адреса из сети 1.1.1.0/24, в которые будем транслировать пакеты, уходящие с интерфейсов GE0/0 и  GE0/1. Для партнера (пакеты, уходящие с интерфейса Tunnel0) головной офис будет транслировать адрес источника в своих пакетах в 192.168.0.0/24. При этом к партнеру мы хотим пускать только пользователей с адресов 10.1.1.0/24, а в интернет 10.2.2.0/24.

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

1. NAT для пакетов, отправляемых в сторону партнера

ip access-list extended  ACL_PARTNER_NAT  - создадим ACL, ограничивающий допуск к сети партнера

 permit ip 10.1.1.0 0.0.0.255 any

route-map RM_PARTNER_NAT permit 10 - создадим рутмап, обеспечивающий выделение нужных потоков для трансляции к партнеру
 match ip address ACL_PARTNER_NAT

 match interface Tunnel0

ip nat pool PARTNER_NAT_POOL 192.168.0.1 192.168.0.254 netmask 255.255.255.0 type rotary - объявляем партнерский NAT POOL 

ip nat inside source route-map RM_PARTNER_NAT pool PARTNER_NAT_POOL overload - настраиваем трансляцию

 

2. NAT для пакетов, отправляемых в Интернет

ip access-list extended  ACL_INTERNET_NAT  - создадим ACL, ограничивающий допуск к Интернету

 permit ip 10.2.2.0 0.0.0.255 any

route-map RM_INETRNET_NAT permit 10 - создадим рутмап, обеспечивающий выделение нужных потоков для трансляции в Интернет
 match ip address ACL_INTERNET_NAT

 match interface GE0/0

route-map RM_INETRNET_NAT permit 20 - и по второму интерфейсу тоже
 match ip address ACL_INTERNET_NAT

 match interface GE0/2

ip nat pool INTERNET_NAT_POOL 1.1.1.1 1.1.1.254 netmask 255.255.255.0 type rotary - объявляем NAT POOL для Интернета

ip nat inside source route-map RM_INTERNET_NAT pool INTERNET_NAT_POOL overload - настраиваем трансляцию



3. Не забываем указать на интерфейсах их роль в NAT-трансляциях

interface GigabitEthernet0/0

ip nat outside

interface GigabitEthernet0/1

ip nat outside

interface Tunnel0

ip nat outside

 

interface GigabitEthernet1/0

ip nat inside

З.Ы. Не заработала конфигурация static route-map NAT + обычный динамический PAT. Если транслируемый адрес подпадал под оба правила, то для трансляции всегда выбирался динамический PAT.