пятница, 27 октября 2017 г.

Некоторые настройки софтроутера

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

ip access-group no-invalid
!
ip access-list no-invalid
 ! 1 permit
 2 deny state invalid
! если имеется вышестоящая конструкция, то она запрещает асимметричный трафик. При ручном направлении трафика, часто бывает, что роутинг становится асимметричным, в этом случае заблаговременно надо, либо убрать "ip access-group no-invalid", либо добавить в ACL no-invalid "1 permit".

Для достижения максимальных скоростей возможно использовать доступные "offload" на интерфейсах (и тюнинг очередей), - они работают.

Всегда использовать принудительное распределение обработки трафика на все процессоры, уменьшает latency.
"уууу хххх  mode sync"
или что-то аналогичное.


четверг, 26 октября 2017 г.

дистрибуция маршрутов из bgp в eigrp

Возникла необходимость доставлять маршруты до сети из роутеров Cisco из vpn L3- хаба подключенных к нему удаленных точек (spoke). L3-хаб работает под управлением cisco-like софтроутера и в нем доступен только протокол маршрутизации BGP. Попытка подключиться Cisco-й к нему по ibgp (т.е. с тем же № AS) аналогично vpn-spoke, выявила что директива  neighbor 10.31.1.6 next-hop-self  в cisco не меняет next-hop и маршруты приходят с оригинальным next-hop, а т.к. они не являются connected, то и не инжектируются в таблицу маршрутизации cisco (в софтроутере же next-hop-self работает правильно и для iBGP (в cisco также указывался нужный bgp cluster-id)) . Было принято решение подключиться к L3-хабу по eBGP, т.е. со сменой № AS. В этом случае маршруты принялись и next-hop-self работает правильно. Затем уже эти маршруты были редистрибутированы в eigrp для доставки дальше по уже работающей сети роутеров с eigrp маршрутизацией. Также описано решение для cisco и для iBGP, с route-map с подменой next-hop, но оно более сложное и перегружает конфигурацию.
Надо учесть что при добавление или удалении сетей в ACL bgp-route-in (out), изменения не произойдут: -маршруты не добавятся и не исчезнут. Для этого необходимо выполнить команду: cle bgp ipv4 uni * soft

!--guagga--

router bgp 65001
 bgp router-id 10.10.10.1
 bgp always-compare-med
 bgp cluster-id 10.10.10.1
 bgp scan-time 30
 network 10.10.10.1/32
 redistribute connected
 redistribute static metric 111
 timers bgp 3 10
 neighbor 10.0.0.102 remote-as 65001
 neighbor 10.0.0.106 remote-as 65001
 neighbor 10.0.0.106 weight 20000
 neighbor 10.31.1.2 remote-as 65002
 neighbor 192.168.255.250 remote-as 65001
 neighbor 192.168.255.250 route-reflector-client
 neighbor 192.168.255.250 next-hop-self
 neighbor 192.168.255.254 remote-as 65001
 neighbor 192.168.255.254 route-reflector-client
 neighbor 192.168.255.254 next-hop-self



!---cisco--
router eigrp 1
! bla-bla
! bla-bla
 redistribute connected
 redistribute bgp 65002 metric 10000 5 255 1 1500
!
router bgp 65002
 bgp router-id 10.31.1.2
 bgp log-neighbor-changes
 bgp redistribute-internal
 network 10.31.1.2
 neighbor 10.31.1.6 remote-as 65001
 neighbor 10.31.1.6 next-hop-self
 default-metric 30000
 distribute-list bgp-route-out out
 distribute-list bgp-route-in in
!
ip access-list standart bgp-route-in
!- needed networks




среда, 11 октября 2017 г.

Конфигурирование BGP на quagga

Возникла задача создать многоточечную сеть ВПН на quagga-like системах с топологией "звезда". Так как кол-во точек могло быть  достаточно большим, а также необходимо чтобы решение было резервируемым, то маршрутизацию решил сделать на BGP, для совместимости с имеющимся оборудованием CISCO, в котором данный протокол уже использовался.
Обычная конфигурация стандартно заработала, но возникла проблема с доставкой маршрутов между удаленными точками: -центральный узел их не отдавал. Почитав мануалы включил route-reflector-client и тут началось странное, на 1-м удаленном роутере всё как должно быть, а на другом, с аналогичной конфигурацией, маршрут приходит, но не инсталлируется в таблицу, причем, если в bgp конфигурации центральной точки убрать и снова прописать route-reflect-client, маршрут на 2-й точке инсталлировался, но потом опять исчезал. Выяснилось, что удаленные точки считают, что они находятся в bgp-кластере с название router-id центральной точки. Указав на центральном узле bgp claster-id равное router-id, вся маршрутизация заработала штатно. Связь между точками осуществлялась по vpn-туннелям с /30 битной адресацией (192.168.255.252/30, 192.168.255.248/30 и т.д.)

!-HUB-
!
router bgp 65000
 bgp router-id 10.10.10.1
 bgp always-compare-med
 bgp cluster-id 10.10.10.1
 network 10.10.10.1/32
 redistribute connected
 neighbor 10.0.0.102 remote-as 65000
 neighbor 10.0.0.106 remote-as 65000
 neighbor 10.0.0.106 weight 20000  !-увеличить вес для маршрутов основного канала
 neighbor 192.168.255.250 remote-as 65000
 neighbor 192.168.255.250 route-reflector-client
 neighbor 192.168.255.250 next-hop-self
 neighbor 192.168.255.254 remote-as 65000
 neighbor 192.168.255.254 route-reflector-client
 neighbor 192.168.255.254 next-hop-self
!
ИЛИ указывать peer через шаблон:
 neighbor intergr peer-group
 neighbor intergr remote-as 65000
 neighbor intergr route-reflector-client
 neighbor intergr next-hop-self
 neighbor intergr soft-reconfiguration inbound
 neighbor 192.168.255.254 peer-group intergr



-----------------------
!-SPOKE-
!
router bgp 65000
 bgp router-id 192.168.50.194
 network 192.168.50.0/24
 networ 192.168.255.254/32
 redistribute connected
 neighbor 192.168.255.253 remote-as 65000
 neighbor 192.168.255.253 next-hop-self ! (не работает если маршрут от 3-го роутера, нужен  "set ip next-hop 192.168.255.253" в route-map )
 neighbor 192.168.255.253 route-map route-in in
 neighbor 192.168.255.253 route-map route-out out
!
!
router prefix-list route-in seq 10 permit 10.0.1.0/24
router prefix-list route-in seq 20 permit 192.168.22.0/24
!
router prefix-list route-out seq 10 permit 192.168.50.0/24
!
router route-map route-in permit 100
 match ip address prefix-list route-in
 set ip next-hop 192.168.255.253
!
router route-map route-out permit 100
 match ip address prefix-list route-out

команды для отладки:

!-HUB-
# show bgp 192.168.50.0/24
BGP routing table entry for 192.168.50.0/24
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.0.0.102 10.0.0.106 192.168.255.250
  Local, (Received from a RR-client)
    192.168.255.254 (metric 1) from 192.168.255.254 (192.168.255.254)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Last update: Tue Oct 10 15:43:22 2017

!-SPOKE-
# show bgp 192.168.22.0/24
BGP routing table entry for 192.168.22.0/24
Paths: (1 available, no best path)
  Not advertised to any peer
  Local
    192.168.255.250 (inaccessible) from 192.168.255.253 (192.168.255.250)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 192.168.255.250, Cluster list: 10.10.10.1
      Last update: Tue Oct 10 16:01:47 2017

show bgp
show ip route bgp



Увеличение объема оперативной памяти RAM в windows XP SP3

Данные действия были навеяны статьёй https://geektimes.ru/post/202406/ , где автор рассказывал о том как добился использования в своей 32-битной windows XP всей памяти, а не 3 ГБ.
В моем случае, в машине было установлено 4 ГБ, но операционная система видела только 3. Сделав всё как в описании и запустив компьютер, добился только черного экрана, после которого можно было перезагрузиться только кнопкой питания. Более того, у меня размер файла ядра был в 20 раз меньше, чем описанный у автора, и патчить его смысла не было, хотя когда он был прописан как KERNEL=krnl386.exe в boot.ini, компьютер нормально загружался.
Затем начался перебор ядер и драйверов HAL.dll , итогом которых удалось понять что мой krnl386.exe лишь заглушка, которая запускает файл ntkrnlpa.exe (в котором и обнаружилась необходимая бинарная последовательность для патча). Это удалось подтвердить вписав напрямую эти названия в файле boot.ini.

multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional RU 4GB RAM" /noexecute=optin /fastdetect KERNEL=ntkrnlpa.exe /hal=hal.dll
в результате ОС нормально загружалась.

файл ntkrnlpa.exe был пропатчен на 16ГБ и сохранен в 4gkrnlpa.exe,
в boot.ini добавлена запись вида:
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional RU 4GB RAM" /noexecute=optin /fastdetect KERNEL=4gkrnlpa.exe /hal=hal.dll /PAE
Система зависала черным экраном и не грузилась, ни в обычном, ни в безопасном режимах.

Выяснилось, что опция "/noexecute=optin" конфликтует с /PAE, когда её исключил, ОС стала загружаться, но только в безопасном режиме, при этом виделось уже 4 ГБ ОЗУ.

Следующим шагом был подбор драйвера HAL.dll, для этих целей был использован файл halmacpi.dll от windows xp sp1. Запись в boot.ini стала следующей:
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional RU 4GB RAM" /fastdetect KERNEL=4gkrnlpa.exe /hal=halmacpi.dll /PAE

В таком виде ОС нормально загрузилась и работает в обычном режиме, память RAM доступна вся. В последствии было добавлено ещё 4 ГБ до 8 ГБ, которые система также увидела. Для теста было создано 2 виртуальных диска в RAM по 2 ГБ, скорость копирования с одного на другой составила 300 МБ/сек.

четверг, 5 октября 2017 г.

Восстановление загрузочного диска с операционной системой (windows xp sp3).

Восстановление загрузочного диска с операционной системой (windows xp sp3). 

После нескольких экспериментов кончавшимися зависаниями и отключением компьютера кнопкой питания, система перестала загружаться, выпадая в BSOD с указанием на ошибку жесткого диска. Загрузившись с usb-флеш (Strelec)  выяснилось, что диск стал определяться как RAW вместо NTFS, а также Windows считал, что есть проблемы с MFT. Проверив его структуру программой R-studio network 7.8.160829 нужный NTFS раздел увиделся, после чего сразу сделал с него образ в .DSK файле. (но если восстанавливать понадобится с помощью программы R-drive image 6.0, то сохранять надо в формате .RDR).
Никакими программами (TestDisk, Minitool Partition Wizard, GetDataBack, DMDE и т.д.) напрямую  восстановить раздел из RAW в NTFS (без копирования всех каталогов и файлов, поменяв только параметры раздела) не удалось. Некоторые программы считают его нормальным или читаемым Active@ Patition Recovery, R-studio, но Acronis видит этот раздел, но считает проблемным, но исправить не может.

В конце концов, пришлось отформатировать партицию средствами Windows (Быстрым форматированием !) с указанием, что он активный и загрузочный (для записывания на него MBR). После чего, образ .DSK был примонтирован программой Eassos Partition Guru V4.7.2.155 Professional, затем все файлы из образа были скопированы на отформатированный  проблемный диск. Если бы образ был в формате .RDR, то диск можно восстановить клонированием прямо из образа программой R-drive, но я не проверял, т.к. изначально сохранил в .DSK.

Загрузившись в восстановленном  таким образом старом Windows XP, в безопасном режиме, запустил chkdsk c: без опции /f, - обнаружились ошибки, затем chkdsk  был запущен с опцией F.