понедельник, 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

среда, 28 сентября 2011 г.

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

вторник, 27 сентября 2011 г.

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 

четверг, 25 августа 2011 г.

Мониторинг трафика на маршрутизаторе 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.

    четверг, 11 августа 2011 г.

    Аутентификация пользователей 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, вводим логин, пароль и убеждаемся, что все работает.



    Ссылки:


    среда, 10 августа 2011 г.

    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.

    Автоматический Backup конфигурации в маршрутизаторах Cisco

    Настроить автоматическое (по таймеру, допустим раз в неделю) сохранение конфигурации маршрутизатора Cisco на tftp или ftp сервер можно:

    1. Повесив на крон выполнение команды «show run» с редиректом.

    1.Сначала определим, ЧТО хотим делать.
    kron policy-list Backup
         cli show run | redirect tftp://10.10.10.10/Cisco_autobackup.conf

    2. Потом обозначим ПЕРИОДИЧНОСТЬ, с которой будем выполнять действие.
    kron occurrence Backup at 23:00 Sun recurring
         policy-list Backup





    Если хотим бэкапить по ftp, то возможны проблемы. На некоторых версиях IOS  есть баг, в результате которого при редиректе на ftp создаются файлы нулевой длины.

    R(config)#file prompt quiet -- чтобы маршрутизатор не задавал лишних вопросов.

    Чтобы этого избежать, можно переписать задание так:

    R(config)#kron policy-list Backup
    R(config-kron-policy)#cli write


    R(config-kron-policy)#cli copy startup-config ftp://user:password@10.10.10.10/Cisco_autobackup.conf
    R(config-kron-policy)#exit


    2. С помощью настройки archive:

    1. Определим параметры коннекта:
    R(config)#ip ftp username user
    R(config)#ip ftp password password
    R(config)#ip ftp source-interface fastEthernet 0/0 - если есть какие-то ограничения по IP

    2. Настроим archive
    R(config)#archive
    R(config-archive)#path ftp://10.10.10.10/cisco/R_autobackup.conf
    R(config-archive)#time-period 10080 -- раз в неделю.




     

    понедельник, 25 июля 2011 г.

    QoS PRE-CLASSIFY и VTI


    Команду qos pre-classify можно применить на VTI интерфейсах, IOS  ее отрабатывает без ошибок, показывает в running-config. Однако, данная команда на VTI не имеет практического  смысла.

    Для VTI  правильно применять service-policy output, используя внутренние адреса, тогда соответсnвующие IPSec пакеты будут корректно прокрашиваться.

     Схема:


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

    class-map VTI_QOS_CLASS
    match access-group name VTI_QOS_ACL
    !
    !
    policy-map VTI_QOS_POLICY
     class VTI_QOS_CLASS
      set dscp ef
    !
    !
    interface Tunnel0
     ip unnumbered Loopback0
     qos pre-classify
     tunnel source 1.1.1.1
     tunnel destination 2.2.2.2
     tunnel mode ipsec ipv4
     tunnel protection ipsec profile VTI
     service-policy output VTI_QOS_POLICY
    !
    !
    ip route 10.20.20.0 255.255.255.0 Tunnel0
    !
    !
    ip access-list extended VTI_QOS_ACL
     permit ip host 10.10.10.10 host 10.20.20.20


    Ссылки:
    Virtual Tunnel Interface (VTI) Design Guide  - раньше был на сайте Cisco, теперь можно найти только в Инете.