http://xgu.ru/wiki/QoS_в_Cisco
Тоже есть парочка интересных моментов. Увлекательно.
Тоже есть парочка интересных моментов. Увлекательно.
понедельник, 26 мая 2014 г.
суббота, 24 мая 2014 г.
QoS кратко и доходчиво
Существует три модели реализации QoS: наилучшая возможная; интегральная и дифференцированная. Наилучший возможный вид услуг реализуется в сети, когда делается все возможное для доставки пакета, но при этом ничего не гарантируется (например FTP или HTTP). Интегрированный вид услуг (RFC-1633, 1994 год) разрабатывался первым и реализуется путем резервирования по схеме точка-точка (протокол RSVP; 1997; см. book.itep.ru/4/44/rsv_4496.htm). Протокол RSVP предоставляет сигнальный механизм для конфигурирования удаленных маршрутизаторов с целью получения нужного QoS. Протокол ориентирован на работу с тремя видами трафика: best efforts (обычная передача IP-данных без установления соединения), чувствительный к скорости передачи и чувствительный к задержкам.Трафик чувствительный к загрузке требует формирования канала с гарантированной пропускной способностью. Приложение при этом вынуждено мириться с определенными задержками доставки (класс услуг с гарантированной скоростью в битах в сек). Третий вид трафика (чувствительный к задержкам) гарантирует минимальную задержку и низкую дисперсию времени доставки. Пропускная способность может при этом варьироваться. Примером такого вида трафика может служить передача голоса или видео. RSVP определяет два типа услуг для этого вида трафика: сервис с контролируемыми задержками и предсказуемый сервис (для приложений реального времени (видео-конференции и телефонные переговоры).
В рамках протокола стандартизованы схемы обработки очередей WFQ (Weighted Fair Queuing) и WRED (Weighted Random Early Detection). В CISCO IOS по умолчанию используется WFQ (для каналов Е1 = 2028 кбит/с или медленнее). Intserv предлагает на L3 тот же уровень услуг, что можно получить в АТМ на уровне L2. В АТМ определены 4 QoS класса:
В рамках протокола стандартизованы схемы обработки очередей WFQ (Weighted Fair Queuing) и WRED (Weighted Random Early Detection). В CISCO IOS по умолчанию используется WFQ (для каналов Е1 = 2028 кбит/с или медленнее). Intserv предлагает на L3 тот же уровень услуг, что можно получить в АТМ на уровне L2. В АТМ определены 4 QoS класса:
- QoS Class 1 (называемый также классом услуг А) имеет те же характеристики, что и выделенный цифровой канал точка-точка
- QoS Class 2 (называемый также классом услуг В) обеспечивает режим, приемлемый для аудио и видео при видеоконференициях или передачи мультимедиа
- QoS Class 3 (называемый также классом услуг 3) обеспечивает режим, приемлемый для передачи, ориентированной на соединение, например, через посредство frame relay.
- QoS Class 4 (называемый также классом услуг 4) эквивалентен режиму IP-передачи в условиях наилучших усилий (best efforts) при отсутствии гарантии доставки.
четверг, 22 мая 2014 г.
среда, 21 мая 2014 г.
вторник, 20 мая 2014 г.
GRE over IPsec
Задача: Необходимо поднять GRE туннель между офисами R5 и R4 и зашифровать его с помощью IPSec (т.н. GRE over IPSec ). Через GRE туннель должна работать маршрутизация типа EIGRP обеспечивая роутинг между локальными сетями офисов через GRE туннель.
Условимся, что EIGRP AS1 у нас имитирует интернет. Вначале настраиваем IP адреса на интерфейсах и EIGRP AS1 маршрутизацию, чтобы приступить к конфигурированию тоннеля.
1) Настраиваем дефолтный маршрут в сторону "провайдера"
R5(config)#ip route 0.0.0.0 0.0.0.0 211.181.24.51
R4(config)#ip route 0.0.0.0 0.0.0.0 211.181.25.112
2) Конфигурируем GRE туннель
-----------------------------
R5(config)#interface Tunnel0
*Mar 1 00:01:47.799: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R5(config-if)#ip address 10.0.100.1 255.255.255.0
R5(config-if)#tunnel source fastEthernet 0/0
R5(config-if)#tunnel destination 211.181.25.221
R5(config-if)#
*Mar 1 00:02:48.707: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R5(config-if)#exit
-----------------------------
R4(config)#int Tunnel0
*Mar 1 00:03:24.595: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R4(config-if)#ip address 10.0.100.2 255.255.255.0
R4(config-if)#tunnel source fastEthernet 0/0
R4(config-if)#tunnel destination 211.181.24.15
R4(config-if)#
*Mar 1 00:04:11.403: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R4(config-if)#exit
-----------------------------
Пингуем и проверяем, что маршрутизация не хромает и нигде не ошиблись в базовой настройке
R4(config)#do ping 10.0.100.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/38/68 ms
R4(config)#
3) Расписываем маршрутизацию EIGRP AS2 на LAN и Туннель
-----------------------------
R5(config)#router eigrp 2
R5(config-router)#no au
R5(config-router)#no auto-summary
R5(config-router)#net
R5(config-router)#network 10.0.100.1 0.0.0.255
R5(config-router)#net
R5(config-router)#network 10.0.1.254 0.0.0.255
R5(config-router)#exit
R5(config)#
*Mar 1 00:20:28.251: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 2: Neighbor 10.0.100.2 (Tunnel0) is up: new adjacency
R5(config)#
-----------------------------
R4(config)#router eigrp 2
R4(config-router)#no au
R4(config-router)#no auto-summary
R4(config-router)#net
R4(config-router)#network 10.0.100.2 0.0.0.255
R4(config-router)#net
R4(config-router)#network
*Mar 1 00:20:18.731: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 2: Neighbor 10.0.100.1 (Tunnel0) is up: new adjacency
R4(config-router)#network 10.0.2.254 0.0.0.255
R4(config-router)#exit
-----------------------------
Проверяем что все настроено правильно и маршрутизация работает
R4(config)#do sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 211.181.25.112 to network 0.0.0.0
C 211.181.25.0/24 is directly connected, FastEthernet0/0
D 211.181.24.0/24 [90/30720] via 211.181.25.112, 00:20:39, FastEthernet0/0
10.0.0.0/24 is subnetted, 3 subnets
C 10.0.2.0 is directly connected, FastEthernet0/1
D 10.0.1.0 [90/297246976] via 10.0.100.1, 00:00:30, Tunnel0
C 10.0.100.0 is directly connected, Tunnel0
S* 0.0.0.0/0 [1/0] via 211.181.25.112
R4(config)#
4) Сконфигурируем ISAKMP
а) Политики
-----------------------------
R5(config)#crypto isakmp enable
R5(config)#crypto isakmp policy 10
R5(config-isakmp)#authentication pre-share
R5(config-isakmp)#encryption des
R5(config-isakmp)#group 2
R5(config-isakmp)#hash sha
R5(config-isakmp)#lifetime 86400
R5(config-isakmp)#exit
-----------------------------
R4(config)#crypto isakmp enable
R4(config)#crypto isakmp policy 10
R4(config-isakmp)#authentication pre-share
R4(config-isakmp)#encryption des
R4(config-isakmp)#group 2
R4(config-isakmp)#hash sha
R4(config-isakmp)#lifetime 86400
R4(config-isakmp)#exit
б) ключи
-----------------------------
R5(config)#crypto isakmp key 0 cisco111 address 211.181.25.221
-----------------------------
R4(config)#crypto isakmp key 0 cisco111 address 211.181.24.15
-----------------------------
5) Задаём трансформу ( вид шифрования трафика в туннеле )
R5(config)#crypto ipsec transform-set CryptoTransformTunnel esp-aes 128
R5(cfg-crypto-trans)#exit
-----------------------------
R4(config)#crypto ipsec transform-set CryptoTransformTunnel esp-aes 128
R4(cfg-crypto-trans)#exit
6) Задаём ACL (карту совпадения) согласно которому будет шифроваться трафик
-----------------------------
R5(config)#access-list 101 permit gre host 211.181.24.15 host 211.181.25.221
-----------------------------
R4(config)#access-list 101 permit gre host 211.181.25.221 host 211.181.24.15
7) Создаём Crypto-Map и применяем на интерфейс
-----------------------------
R5(config)#crypto map MapOffice 5 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
R5(config-crypto-map)#match address 101
R5(config-crypto-map)#set peer 211.181.25.221
R5(config-crypto-map)#set transform-set CryptoTransformTunnel
R5(config-crypto-map)#set pfs group1
R5(config-crypto-map)#set security-association lifetime seconds 86400
R5(config-crypto-map)#exit
R5(config)#int fa 0/0
R5(config-if)#crypt
R5(config-if)#crypto map MapOffice
R5(config-if)#
-----------------------------
ISAKMP включился -- настроен потенциально верно
*Mar 1 07:55:24.074: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R5(config-if)#
-----------------------------
Регистрация события -- получен не IPSec
*Mar 1 07:55:25.158: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.
(ip) vrf/dest_addr= /211.181.24.15, src_addr= 211.181.25.221, prot= 47
R5(config-if)#
-----------------------------
GRE туннель опущен из-за несовместимости IPSec на концах туннеля
*Mar 1 07:55:35.226: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 2: Neighbor 10.0.100.2 (Tunnel0) is down: holding time expired
R5(config-if)#exit
R5(config)#do ping 10.0.100.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.100.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R5(config-if)#
*Mar 1 07:56:29.770: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.
(ip) vrf/dest_addr= /211.181.24.15, src_addr= 211.181.25.221, prot= 47
R5(config-if)#
-----------------------------
Теперь настраиваем IPSec с другой стороны
Прогнозируемый результат:
-- установление IPSec туннеля
-- повторное автоматическое поднятие GRE туннеля теперь с IPSec шифрацией трафика
-- повторное установление EIGRP соседства и возобновление маршрутизации
Как и ожидалось туннель GRE опустился как показано выше с момента как был включен IPSec на другой стороне
*Mar 1 07:55:29.374: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 2: Neighbor 10.0.100.1 (Tunnel0) is down: holding time expired
R4(config)#crypto map MapOffice 5 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
R4(config-crypto-map)#match address 101
R4(config-crypto-map)#set peer 211.181.24.15
R4(config-crypto-map)#set transform-set CryptoTransformTunnel
R4(config-crypto-map)#set pfs group1
R4(config-crypto-map)#set security-association lifetime seconds 86400
R4(config-crypto-map)#exit
R4(config)#int fa 0/0
R4(config-if)#cryp
R4(config-if)#crypto map MapOffice
R4(config-if)#
*Mar 1 08:20:26.289: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R4(config-if)#
-----------------------------
Прогнозируемое поднятие туннеля GRE и возобновление соседства
*Mar 1 08:20:27.573: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 2: Neighbor 10.0.100.1 (Tunnel0) is up: new adjacency
R4(config-if)#
-----------------------------
Проверка пинга и прохождения пакетов через туннель
R4#ping 10.0.100.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/68/120 ms
R4#show crypto ipsec sa
interface: FastEthernet0/0
Crypto map tag: MapOffice, local addr 211.181.25.221
protected vrf: (none)
local ident (addr/mask/prot/port): (211.181.25.221/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (211.181.24.15/255.255.255.255/47/0)
current_peer 211.181.24.15 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 141, #pkts encrypt: 141, #pkts digest: 141
#pkts decaps: 148, #pkts decrypt: 148, #pkts verify: 148
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0
-----------------------------
Проверка роутинга
R4#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 211.181.25.112 to network 0.0.0.0
C 211.181.25.0/24 is directly connected, FastEthernet0/0
D 211.181.24.0/24 [90/30720] via 211.181.25.112, 08:30:31, FastEthernet0/0
10.0.0.0/24 is subnetted, 3 subnets
C 10.0.2.0 is directly connected, FastEthernet0/1
D 10.0.1.0 [90/297246976] via 10.0.100.1, 00:10:13, Tunnel0
C 10.0.100.0 is directly connected, Tunnel0
S* 0.0.0.0/0 [1/0] via 211.181.25.112
R4#
8) Убедиться что трафик идущий через тоннель шифрован
а) Убедиться что данные зашифрованы IPSec
Подключить Wireshark на интерфейс fa0/0 R5 и начать обмен данными между хостами (скачивать файл например). Сразу заметно, что данные только в зашифрованном виде (здесь был пущен банальный пинг по туннелю)
б) Убедиться, что данные идут по GRE туннелю (хотя это очевидно из построенной маршрутизации, проверить лишним не будет)
-----------------------------
Даём пинг с хоста xp_http_ftp_cisco(10.0.1.2) на хост xp_http_ftp_cisco1(10.0.1.2)
admin>ping 10.0.2.2
Обмен пакетами с 10.0.2.2 по 32 байт:
Ответ от 10.0.2.2: число байт=32 время=136мс TTL=126
Ответ от 10.0.2.2: число байт=32 время=145мс TTL=126
Ответ от 10.0.2.2: число байт=32 время=119мс TTL=126
Ответ от 10.0.2.2: число байт=32 время=98мс TTL=126
-----------------------------
Теперь опускаем GRE туннель
R4(config)#int Tunnel 0
R4(config-if)#sh
R4(config-if)#
*Mar 1 08:38:45.365: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 2: Neighbor 10.0.100.1 (Tunnel0) is down: interface down
R4(config-if)#
*Mar 1 08:38:47.181: %LINK-5-CHANGED: Interface Tunnel0, changed state to administratively down
*Mar 1 08:38:48.181: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R4(config-if)#
-----------------------------
И повторяем пинг
admin>ping 10.0.2.2
Обмен пакетами с 10.0.2.2 по 32 байт:
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Настройка и проверка завершены. Поставленная задача достигнута.
воскресенье, 18 мая 2014 г.
Log Commands
С версии IOS 12.2(25)S Cisco добавили функционал позволяющий вести журнал ВСЕХ изменений вносимых в running config.
Режим конфигурации archive добавлен в IOS для реализации механизма сохранения конфигурационных файлов (формирования архива конфигураций). Также в нем реализован механизм ведения журнала всех изменений конфигурации.
Наcтройка
(config)#archive
(config-archive)#log config
(config-archive-log-cfg)#logging enable
(config-archive-log-cfg)#logging size 500
(config-archive-log-cfg)#notify syslog
(config-archive-log-cfg)#hidekeys
(config-archive-log-cfg)#exit
(config-archive)#exit
(config)#exit
Результат можно смотреть в разных вариантах с разной цельюR1#show history
conf t
show logging
show logging his
show logging count
show logging xml
show login
conf t
show history
R1#show history all
*Mar 1 00:00:08.275: %SNMP-5-COLDSTART: SNMP agent on host R1 is undergoing a cold start
*Mar 1 00:00:08.499: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
*Mar 1 00:00:08.503: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
*Mar 1 00:00:09.723: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 1 00:00:09.727: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively downCMD: conf t' 00:00:50 UTC Fri Mar 1 2002
CMD: 'archive ' 00:01:03 UTC Fri Mar 1 2002
CMD: 'log config' 00:01:08 UTC Fri Mar 1 2002
CMD: 'logg' 00:01:11 UTC Fri Mar 1 2002
CMD: 'logging ' 00:01:13 UTC Fri Mar 1 2002
CMD: 'logging enable' 00:01:17 UTC Fri Mar 1 2002
CMD: 'logging size ' 00:01:22 UTC Fri Mar 1 2002
CMD: 'logging size 200' 00:01:27 UTC Fri Mar 1 2002
CMD: 'nnoti' 00:01:33 UTC Fri Mar 1 2002
CMD: 'noti' 00:01:35 UTC Fri Mar 1 2002
CMD: 'notify syslog' 00:01:39 UTC Fri Mar 1 2002
*Mar 1 00:01:39.087: %PARSER-5-CFGLOG_LOGGEDCMD: User:console logged command:notify syslog CMD: 'hide' 00:0:42 UTC Fri Mar 1 2002
CMD: 'hidekeys ' 00:01:50 UTC Fri Mar 1 2002
*Mar 1 00:01:50.043: %PARSER-5-CFGLOG_LOGGEDCMD: User:console logged command:hidekeys CMD: 'exit' 00:01:52 TC Fri Mar 1 2002
*Mar 1 00:01:52.747: %PARSER-5-CFGLOG_LOGGEDCMD: User:console logged command:exit CMD: 'exit' 00:01:53 UTC ri Mar 1 2002
*Mar 1 00:01:53.575: %PARSER-5-CFGLOG_LOGGEDCMD: User:console logged command:exit CMD: 'exit' 00:01:54 UTC ri Mar 1 2002
*Mar 1 00:01:54.407: %SYS-5-CONFIG_I: Configured from console by consoleCMD: 'sgow log' 00:02:02 UTC Fri Mar1 2002
CMD: 'sgow log' 00:02:03 UTC Fri Mar 1 2002
CMD: 'show log' 00:02:07 UTC Fri Mar 1 2002
CMD: 'show logging' 00:02:14 UTC Fri Mar 1 2002
CMD: 'show logging ' 00:02:47 UTC Fri Mar 1 2002
CMD: 'show logging his' 00:02:51 UTC Fri Mar 1 2002
CMD: 'show logging count' 00:03:13 UTC Fri Mar 1 2002
CMD: 'show logging xml' 00:03:18 UTC Fri Mar 1 2002
CMD: 'show lo' 00:03:29 UTC Fri Mar 1 2002
CMD: 'show log' 00:03:31 UTC Fri Mar 1 2002
CMD: 'show log' 00:03:32 UTC Fri Mar 1 2002
CMD: 'show login' 00:03:35 UTC Fri Mar 1 2002
CMD: 'kron ' 00:04:50 UTC Fri Mar 1 2002
CMD: 'wr' 00:12:00 UTC Fri Mar 1 2002
CMD: 'wrr-queue ' 00:12:01 UTC Fri Mar 1 2002
CMD: 'show his' 00:15:23 UTC Fri Mar 1 2002
CMD: 'show hist' 00:15:24 UTC Fri Mar 1 2002
*Mar 1 00:15:26.903: %SYS-5-CONFIG_I: Configured from console by consoleCMD: 'show his' 00:15:28 UTC Fri Mar1 2002
CMD: 'show history ' 00:15:30 UTC Fri Mar 1 2002
CMD: 'show history ' 00:15:32 UTC Fri Mar 1 2002
CMD: 'show history all' 00:15:39 UTC Fri Mar 1 2002
R1#
Автоматическое сохранение конфигурационых файлов
Вытянуто с хабра (http://habrahabr.ru/post/171681/)
Зачем сохранять конфигурацию? Примеров много — может сгореть железка — ее вы можете поменять без проблем, а бэкапа конфигурационного файла нету — придется настраивать с нуля. Хорошо, если у вас хорошая память (и вы помните все настройки) или у вас все полностью описано система. Но что, если конфигурационный файл занимает тысячи строк?
Или к примеру один из сотрудников случайно почистит файл конфигурации или удалит. Возможно преднамеренно…
Можно хранить конфигурацию не во flash — а на внешнем носителе или удаленном сервере — но потерять конфигурацию можно и в этом случае. Бэкап конфигурации делать нужно обязательно — и на постоянной основе.
Я опишу, как можно автоматизировать данный процесс.
В начале, требуется поднять TFTP сервер (так же можно использовать FTP либо другой способ, я сохраняю в конфигурации по локальной сети в отдельном менеджмент VLAN — поэтому использую TFTP без аутентификации).
Под TFTP-сервер возможно использовать как Linux — так и Windows сервера, у меня для этих целей есть сервер с ОС Windows 2012. Под него нужно скачать TFTP сервер — я для этих целей использую бесплатную tftpd32 service edition, она устанавливается и подымается как сервис в системе. Запускаем программу, указываем ей папку, в которой будет сохранятся конфигурационный файлы, указываем какой IP она будет использовать и проверяем доступность TFTP-сервера с маршрутизатора простым копированием файла с внутреннего flash:
У меня во внутренней памяти маршрутизатора лежал файл «3.txt» — и я его успешно скопировал на TFTP-сервер.
Способ первый. Создание задания kron.
1) Создание скрипта-политики для бэкапа:
Router(config)#kron policy-list (имя)
Router(config-kron-policy)#cli copy (откуда копировать) (куда копировать)
Router(config-kron-policy)#exit
где следующие параметры:
сli — определение EXEC CLI команды в задании политики.
policy-list — определение политики, которая будет ассоциироваться с заданием в инструкции.
Пример:
2) Создается инструкция для устройств c временем и интервалом выполнения задания:
Router(config)#kron occurrence (name) at (hh:mm) (day/month/oneshot/reccuring)
Router(config-kron-occurrence)#policy-list (имя)
Пример:
3) Проверка конфигурации командой show kron.
Способ второй. Создание архивирования.
Архивирование появилось в устройствах с версии 12.3 — поэтому, возможно придется обновлять iOS. В данный момент для многих устройств уже используются iOS от версии 15.x и выше. Соответственно на старых устройствах данный функционал не поддерживается.
Посмотрим параметры данной команды:
опишу каждый параметр:
log — настройка логирования;
maximum — максимальное количество резервных копий конфигурации (по умолчанию 10);
path — путь, который указывает где хранятся резервные копии. При задании имени файла можно использовать переменные $H — имя устройства, и $T — текущее время;
time-period — период времени через который будет автоматически выполняться архивирование текущей конфигурации (в мин), если выставить значение 1440 (24 часа), то сохраняться будет каждые сутки и при сохранении конфигурации устройства;
write-memory — включает автоматическую генерацию резервной копии конфигурации, после выполнения сохранения конфигурации;
hidekeys — скрывать пароли при архивации (хотя никто не отменял использование secret вместо password).
посмотрим возможные пути для сохранения архивов:
Команда так же позволяет сохранять конфигурацию в различные места.
Настройка сохранения на TFTP будет выглядеть следующим образом:
Теперь при каждом выполнении команды сохранения конфига на устройстве создастся файл на удаленном tftp сервере.
Проверяем работоспособность, сохраняем конфигурацию:
И смотрим сохраненные архивы:
Видно что создан один архив.
У команды еще одна полезная фича — сравнение архивов.
Сделаем (сохранив конфигурацию) еще один архив и проверим их различия командой:
Router# sh archive config differences (name1) (name2)
Пример:
Различий нет — архивы одинаковы.
Так же есть существует способ восстановления предыдущей версии архива командой:
Второй способ удобнее, так как позволяет сделать бэкап при каждом сохранение конфигурации — а значит и возможность откатиться к последней (даже десяти последним) конфигурациям, но его минус — не поддерживается старыми iOS. Для меня данная проблема не актуально — поэтому я использую archive.
Зачем сохранять конфигурацию? Примеров много — может сгореть железка — ее вы можете поменять без проблем, а бэкапа конфигурационного файла нету — придется настраивать с нуля. Хорошо, если у вас хорошая память (и вы помните все настройки) или у вас все полностью описано система. Но что, если конфигурационный файл занимает тысячи строк?
Или к примеру один из сотрудников случайно почистит файл конфигурации или удалит. Возможно преднамеренно…
Можно хранить конфигурацию не во flash — а на внешнем носителе или удаленном сервере — но потерять конфигурацию можно и в этом случае. Бэкап конфигурации делать нужно обязательно — и на постоянной основе.
Я опишу, как можно автоматизировать данный процесс.
В начале, требуется поднять TFTP сервер (так же можно использовать FTP либо другой способ, я сохраняю в конфигурации по локальной сети в отдельном менеджмент VLAN — поэтому использую TFTP без аутентификации).
Под TFTP-сервер возможно использовать как Linux — так и Windows сервера, у меня для этих целей есть сервер с ОС Windows 2012. Под него нужно скачать TFTP сервер — я для этих целей использую бесплатную tftpd32 service edition, она устанавливается и подымается как сервис в системе. Запускаем программу, указываем ей папку, в которой будет сохранятся конфигурационный файлы, указываем какой IP она будет использовать и проверяем доступность TFTP-сервера с маршрутизатора простым копированием файла с внутреннего flash:
RT-01#copy flash: tftp:
Source filename []? 3.txt
Address or name of remote host []? 192.168.10.24
Destination filename [3.txt]?
!!!
11335 bytes copied in 0.044 secs (257614 bytes/sec)
RT-01#
У меня во внутренней памяти маршрутизатора лежал файл «3.txt» — и я его успешно скопировал на TFTP-сервер.
Способ первый. Создание задания kron.
1) Создание скрипта-политики для бэкапа:
Router(config)#kron policy-list (имя)
Router(config-kron-policy)#cli copy (откуда копировать) (куда копировать)
Router(config-kron-policy)#exit
где следующие параметры:
сli — определение EXEC CLI команды в задании политики.
policy-list — определение политики, которая будет ассоциироваться с заданием в инструкции.
Пример:
RT-01(config)#kron policy-list conf_to_tftp
RT-01(config-kron-policy)#cli copy system:/running-config tftp://192.168.10.24/rt-01.txt
2) Создается инструкция для устройств c временем и интервалом выполнения задания:
Router(config)#kron occurrence (name) at (hh:mm) (day/month/oneshot/reccuring)
Router(config-kron-occurrence)#policy-list (имя)
Пример:
RT-01(config)#kron occurrence daily at 4:00 recurring
RT-01(config-kron-occurrence)#policy-list conf_to_tftp
3) Проверка конфигурации командой show kron.
RT-01#sh kron schedule
Kron Occurrence Schedule
daily inactive, will run again in 0 days 15:04:22 at 4 :00 on
Способ второй. Создание архивирования.
Архивирование появилось в устройствах с версии 12.3 — поэтому, возможно придется обновлять iOS. В данный момент для многих устройств уже используются iOS от версии 15.x и выше. Соответственно на старых устройствах данный функционал не поддерживается.
Посмотрим параметры данной команды:
RT-01(config)#archive
RT-01(config-archive)#?
Archive configuration commands:
default Set a command to its defaults
exit Exit from archive configuration mode
log Logging commands
maximum maximum number of backup copies
no Negate a command or set its defaults
path path for backups
rollback Rollback parameters
time-period Period of time in minutes to automatically archive the running-config
write-memory Enable automatic backup generation during write memory
опишу каждый параметр:
log — настройка логирования;
maximum — максимальное количество резервных копий конфигурации (по умолчанию 10);
path — путь, который указывает где хранятся резервные копии. При задании имени файла можно использовать переменные $H — имя устройства, и $T — текущее время;
time-period — период времени через который будет автоматически выполняться архивирование текущей конфигурации (в мин), если выставить значение 1440 (24 часа), то сохраняться будет каждые сутки и при сохранении конфигурации устройства;
write-memory — включает автоматическую генерацию резервной копии конфигурации, после выполнения сохранения конфигурации;
hidekeys — скрывать пароли при архивации (хотя никто не отменял использование secret вместо password).
посмотрим возможные пути для сохранения архивов:
RT-01(config-archive)#path?
flash0: Write archive on flash0: file system
flash1: Write archive on flash1: file system
flash: Write archive on flash: file system
ftp: Write archive on ftp: file system
http: Write archive on http: file system
https: Write archive on https: file system
rcp: Write archive on rcp: file system
scp: Write archive on scp: file system
tftp: Write archive on tftp: file system
Команда так же позволяет сохранять конфигурацию в различные места.
Настройка сохранения на TFTP будет выглядеть следующим образом:
RT-01(config)#archive
log config
logging enable
logging persistent reload
hidekeys
path tftp://192.168.10.24/$H-$T
write-memory
Теперь при каждом выполнении команды сохранения конфига на устройстве создастся файл на удаленном tftp сервере.
Проверяем работоспособность, сохраняем конфигурацию:
RT-01#wr
Building configuration…
[OK]!
И смотрим сохраненные архивы:
RT-01#sh archive
The maximum archive configurations allowed is 10.
The next archive file will be named tftp://192.168.10.24/RT-01-Mar--5-13-17-00.303.txt-1
Archive # Name
1 tftp://192.168.10.24/RT-01-Mar--5-13-16-56.343.txt-0 < — Most Recent
2
3
4
5
6
7
8
9
10
Видно что создан один архив.
У команды еще одна полезная фича — сравнение архивов.
Сделаем (сохранив конфигурацию) еще один архив и проверим их различия командой:
Router# sh archive config differences (name1) (name2)
Пример:
RT-01#sh archive config differences tftp://192.168.10.24/RT-01-Mar--5-13-16-56.343.txt-0 tftp://192.168.10.24/RT-01-Mar--5-13-20-30.647.txt-1
Loading RT-01-Mar--5-13-16-56.343.txt-0 from 192.168.10.24 (via Port-channel1):!
[OK — 6663 bytes]
Loading RT-01-Mar--5-13-20-30.647.txt-1 from 192.168.10.24 (via Port-channel1):!
[OK — 6663 bytes]
!Contextual Config Diffs:
!No changes were found
Различий нет — архивы одинаковы.
Так же есть существует способ восстановления предыдущей версии архива командой:
RT-01(config)#configure replace tftp://192.168.10.24/RT-01-Mar--5-13-20-30.647.txt-1
Второй способ удобнее, так как позволяет сделать бэкап при каждом сохранение конфигурации — а значит и возможность откатиться к последней (даже десяти последним) конфигурациям, но его минус — не поддерживается старыми iOS. Для меня данная проблема не актуально — поэтому я использую archive.
IP inspect
Итак ещё раз про IP inspect
Есть ситуация, у нас стоит Cisco Firewall типа ASA или PIX. В локальной сети сидит боец невидимого фронта(10.0.0.3) который мечтает соединиться с сервером (172.30.1.50) по телнету (порт 23 протокол TCP). Оставим вопрос: "зачем это нужно пьяному гусару?" -- на усмотрение самого пьяного гусара и обратимся к стульям.
Чтобы обеспечить такое соединение нужно обеспечить 2 этапа
Этап 1: Трафик должен пройти из [ зоны Inside] --> в --> [ зону Outside ]
логично прописать ему access-list вида:
ASA(config)# access-list 101 permit tcp any any eq 23
Такой вариант написания листа доступа годится для начинающего CCNA асистента, даже работать будет, но это слишком общее правило чтобы им вот так разбрасываться
Более точный и разумный он будет такой:
ASA(config)# access-list 101 permit tcp host 10.0.0.3 host 172.30.1.50 any eq 23
можно ещё шлифануть его на предмет Time-Based, но это уже надо регламент работы организации смотреть и на должность пьяного гусара :)
Итак трафик благополучно преодолел пределы атмосферы и улетел в открытый космос в сторону сервера, предположим, что он даже благополучно вернулся к нашему файерволу, тут начинается этап 2
Этап 2: Трафик должен пройти обратно из [ зоны Outside] --> в --> [ зону Inside ]
Но у нас неувязка, согласно регламенту компании на интерфейсе Outside, в направлении in, должно всегда висеть правило:
deny ip any any
и оно не предполагает исключений ни для влюблённых, ни для инопланетян. Как же быть?
Попробуем сделать финт ушами и применить фишечку под названием IP inspect. Суть работы IP inspect в нашем случае заключается в просмотре и запоминании трафика который инициирован изнутри, чтобы затем пропустить его так же мягко и нежно снаружи обратно, когда он вернётся (за кадром он на самом деле создаёт динамический ACL на ходу, и сразу же его убивает когда сессия закрывается).
Если же пришедший трафик не соответствует никакой сессии, на следующем логическом шаге маршрутизатор проверяет ACL, висящий на интерфейсе, на предмет наличия правила для этого трафика. В нашем случае это будет deny ip any any. И любой трафик не иницированный изнутри будет дохнуть прямо на точке входа.
Вернёмся к нашим
ip inspect name FWRULE tcp
и применяем его на интерфейс в направлении in
(config-if)# ip inspect FWRULE in
Услышав удовлетворённый вздох гусара, достигшего высшей точки удовольствия от соединения по телнету, возвращаемся обратно к работе.
P.S. На самом деле на ASA/PIX конфигурация IP inspect не настолько проста ( подробно см. по метке IP inspect ), здесь приведён только сам принцип.
суббота, 17 мая 2014 г.
IPSec Error Debug Configuration
Use the debug crypto isakmp command to troubleshoot this issue, as shown in Example 8-56.
Example 8-56. Responder Has No Preshared Key for the Initiator
Osaka#debug crypto isakmp Crypto ISAKMP debugging is on *May 13 16:57:07.283 GMT: ISAKMP (0:2): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH Old State = IKE_READY New State = IKE_R_MM1 *May 13 16:57:07.283 GMT: ISAKMP (0:2): processing SA payload. message ID = 0 *May 13 16:57:07.283 GMT: ISAKMP (0:2): No pre-shared key with 172.16.5.1! *May 13 16:57:07.283 GMT: ISAKMP (0:2): Checking ISAKMP transform 1 against priority 10 policy *May 13 16:57:07.283 GMT: ISAKMP: encryption DES-CBC *May 13 16:57:07.283 GMT: ISAKMP: hash MD5 *May 13 16:57:07.283 GMT: ISAKMP: default group 1 *May 13 16:57:07.283 GMT: ISAKMP: auth pre-share *May 13 16:57:07.283 GMT: ISAKMP: life type in seconds *May 13 16:57:07.283 GMT: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 *May 13 16:57:07.283 GMT: ISAKMP (0:2): Preshared authentication offered but does not match policy! *May 13 16:57:07.283 GMT: ISAKMP (0:2): atts are not acceptable. Next payload is 0 *May 13 16:57:07.283 GMT: ISAKMP (0:2): Checking ISAKMP transform 1 against priority 65535 policy *May 13 16:57:07.283 GMT: ISAKMP: encryption DES-CBC *May 13 16:57:07.283 GMT: ISAKMP: hash MD5 *May 13 16:57:07.283 GMT: ISAKMP: default group 1 *May 13 16:57:07.283 GMT: ISAKMP: auth pre-share *May 13 16:57:07.283 GMT: ISAKMP: life type in seconds *May 13 16:57:07.283 GMT: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 *May 13 16:57:07.283 GMT: ISAKMP (0:2): Hash algorithm offered does not match policy! *May 13 16:57:07.287 GMT: ISAKMP (0:2): atts are not acceptable. Next payload is 0 *May 13 16:57:07.287 GMT: ISAKMP (0:2): no offers accepted! *May 13 16:57:07.287 GMT: ISAKMP (0:2): phase 1 SA not acceptable! *May 13 16:57:07.287 GMT: ISAKMP (0:2): incrementing error counter on sa: construct_fail_ag_init *May 13 16:57:07.287 GMT: ISAKMP (0:2): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE Old State = IKE_R_MM1 New State = IKE_R_MM1 *May 13 16:57:07.287 GMT: ISAKMP (0:2): Input = IKE_MESG_INTERNAL, IKE_PROCESS_ERROR Old State = IKE_R_MM1 New State = IKE_READY Osaka#In highlighted line 1, the IKE state changes from IKE_READY to IKE_R_MM1. Osaka has received the first message in the main mode exchange from router Tokyo. Note the R in the output here—it indicates that Osaka is the responder.
Osaka then begins to process the SA payload (highlighted line 2), but in highlighted line 3, it reports that it does not have a preshared key for the initiator.
Osaka continues to process the SA payload in the following lines, but in highlighted line 4, the IKE state changes back to IKE_READY, indicating that phase 1 negotiation has failed.
The reason for the failure was, of course, indicated in highlighted line 3. Osaka does not have a preshared key for Tokyo.
Osaka's configuration is then examined using the show running-config command as demonstrated in Example 8-57. Note that only the relevant portion of the output is shown.
Example 8-57. Osaka's Configuration
Osaka#show running-config Building configuration... ! crypto isakmp policy 10 hash md5 authentication pre-share crypto isakmp key cisco address 172.16.4.1 !As you can see, there is only one preshared key configured, and it is configured for peer 172.16.4.1. In fact, there is no such peer—it should be 172.16.5.1 (Tokyo).
The preshared key is then reconfigured, as shown in Example 8-58.
Example 8-58. Reconfiguration of the Preshared Key
Osaka#conf t Enter configuration commands, one per line. End with CNTL/Z. Osaka(config)#no crypto isakmp key cisco address 172.16.4.1 Osaka(config)#crypto isakmp key cisco address 172.16.5.1 Osaka(config)#exit Osaka#The highlighted lines show where the preshared key is reconfigured.
Once the preshared key has been reconfigured, IKE phase 1 negotiation is successful, as shown in Example 8-59.
Example 8-59. IKE Phase 1 Negotiation Succeeds
Osaka#show crypto isakmp sa dst src state conn-id slot 172.16.6.2 172.16.5.1 QM_IDLE 9 0 Osaka#
пятница, 16 мая 2014 г.
IPSec более подробно
Концепция site-to-site VPN и Remote Vpn
Так выглядят 2 основных концепта построения IPSec
2 обобщённые комбинации
Подробное рассмотрение составлящих IPSec
Две разновидности IPSec: AH и ESP. AH не шифрует трафик, потому сразу на помойку, приведено только для общей информации
AH
И, наконец, самое вкусное, ESP
Security Associations
An SA is a basic building block of IPsec. Security associations are maintained within a SA database (SADB), which is established by each device. A VPN has SA entries defining the IPsec encryption parameters as well as SA entries defining the key exchange parameters.
All cryptographic systems, including the Caesar cipher, Vigenere cipher, Enigma machine, to modern encryption algorithms, must deal with key management issues. Diffie-Hellman (DH) is used to create the shared secret key. However, IPsec uses the Internet Key Exchange (IKE) protocol to establish the key exchange process.
Instead of transmitting keys directly across a network, IKE calculates shared keys based on the exchange of a series of data packets. This disables a third party from decrypting the keys even if the third party captured all exchanged data that is used to calculate the keys.
IKE is layered on UDP and uses UDP port 500 to exchange IKE information between the security gateways. UDP port 500 packets must be permitted on any IP interface involved in connecting a security gateway peer.
IKE is defined in RFC 2409. It is a hybrid protocol, combining the Internet Security Association and Key Management Protocol (ISAKMP) and the Oakley and Skeme key exchange methods. ISAKMP defines the message format, the mechanics of a key-exchange protocol, and the negotiation process to build an SA for IPsec. ISAKMP does not define how keys are managed or shared between the two IPsec peers. Oakley and Skeme have five defined key groups. Of these groups, Cisco routers support Group 1 (768-bit key), Group 2 (1024-bit key), and Group 5 (1536-bit key).
IKE combines these protocols to build secure IPsec connections between devices. It establishes SAs that are mutually agreeable to each peer. Each peer must have identical ISAKMP and IPsec parameters to establish an operational and secure VPN. Note that the terms ISAKMP and IKE are commonly used by industry people to refer to IKE.
An alternative to using IKE is to manually configure all parameters required to establish a secure IPsec connection. This process is impractical because it does not scale.
Phase 1 - Two IPsec peers perform the initial negotiation of SAs. The basic purpose of Phase 1 is to negotiate IKE policy sets, authenticate the peers, and set up a secure channel between the peers. It can be implemented in main mode (longer, initial contact) or aggressive mode (after initial contact).
Phase 2 - SAs are negotiated by the IKE process ISAKMP on behalf of IPsec. It can be negotiated in quick mode.
Общая схема выглядит вот так, но ОНА ТУПАЯ
-------------------------------------------------------------------------------------------
Непосредственно конфигурация по делу
Подписаться на:
Сообщения (Atom)