Dreamcatcher.ru

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

 Итак, вкратце опишу положение на начало проекта:

• Имеется 70 филиалов, подключенных магистральными каналами к маршрутизатору ЦО
• В большинстве филиалов имеются каналы Интернет, подключенных на неподконтрольное ЦО оборудование, внутренним интерфейсом смотрящее в LAN филиала
• Администраторы филиалов самостоятельно поднимают VPN через Интернет на базе OpenVPN, MS ISA, MS RAS и т.д. с миниофисами своего региона. Так же, через внешний шлюз публикуются почтовые сервисы, используется прокси-сервер
• На уровне ЦО и магистрального оборудования филиалов используются маршрутизаторы Cisco
• Между организацией и магистральным провайдером был организован BGP, по которому шел обмен маршрутной информацией в том числе и о внутренних сетях.

 Ранее пакетной фильтрации между филиалами и ЦО не осуществлялось, накладывались ACL на магистральные интерфейсы, но в подавляющем большинстве случаев они не соответствовали действительности. По MPLS сети провайдера ходили все маршруты, защита передаваемых данных не осуществлялась, так как я длительное время работал в банковской среде, это показалось мне диким. На значительную часть оборудования у администраторов ЦО не было доступа, в филиалах процветали сепаратистские настроения. Имеющуюся на начало проекта схему связи я выкладывать не буду, так как ничего интересного на ней нет, сплошной шок и трепет.

 Было принято решение привести все филиалы к более-менее однообразной схеме организации каналов связи, установка типовых межсетевых экранов Cisco ASA 5505 для подключения каналов Интернет, осуществление пакетной фильтрации между филиалами и ЦО.

 Новые схемы подключения представлены на рисунках №1 и №2.

 Оценочное суждение: уровень технической подготовки администраторов, в плане телекоммуникаций, черезвычайно низок. Это связано, я считаю, в первую очередь с тем, что с администраторами филиалов не проводилась работа из ЦО. По сути дела, они были брошены на произвол судьбы и были вынуждены самостоятельно искать решения телекоммуникационных вопросов, работая по неким how-to, не понимая сути и смысла. Из этого следует вывод №1 — с кадрами надо работать.

 Лично я предпочитаю, при постановке задач филиалам, рассылать подробнейшие инструкции, с указанием не только того ЧТО надо делать, но и ЗАЧЕМ это необходимо.

 Исходя из имеющегося опыта работы с сетью филиалов в нескольких крупных компаниях, можно сделать вывод, что порядка 30% личного состава администраторов проявляют разумную инициативу, готовы к изменениям, если они направлены на улучшение работы. 50% администраторов пассивны и выполняют поставленные задачи без энтузиазма, с периодическим взбадриванием. Еще 10% считают, что они больше тебя знают о твоей работе, сами поддерживают свою сеть и обращаются за помощью только в случае неисправности, справиться с которой не в состоянии. Оставшиеся 10% не способны на осмысленную деятельность.

 Весьма важной задачей администратора ЦО является перехват функций настройки и контроля оборудования в филиалах. Это необходимо для эффективной работы, так как не контролируя сеть невозможно поддерживать ее функционирование. Конечно, это повлечет повышение нагрузки на администраторов ЦО, но преимуществ будет значительно больше — управляемость, безопасность, независимость от администратора ЦО. Проявления сепаратизма в филиалах должны быть пресечены мгновенно и максимально жестко, с доведением информации до всех администраторов. Можно пойти по пути разделения зон ответственности, когда очерчивается граница между оборудованием, обслуживаемым администратором ЦО и администратором филиала, отказав в решении проблем в зоне ответственности филиала, но это не продуктивно, так как весьма затруднится перестройка и модернизация сети.

 Не стоит забывать о человеческих отношениях, Необходимо постараться, чтобы с администраторами филиалов были выстроены дружественные отношения, но без панибратсва, так как это будет мешать работе. С учетом вышесказанного, как никогда актуальна фраза: «Добрым словом и пистолетом можно добиться большего, чем одним добрым словом».

 Большое внимание следует уделять документированию сети. В этом неоценимую помощь может оказать внятное наименование устройств, наличие description на сетевых интерфейсах и создание резервных копий конфигураций устройств.

 В случае с маршрутизаторами Cisco, создание резервных копий конфигураций устройств удобно делать с помощью rsh/rcp. У отдела телекоммуникаций имеется некий сервер, осуществляющий сбор конфигураций, также, вся работа с оборудованием осуществляется с этого сервера, что позволяет не плодить лишние правила на МСЭ.

 Для удобства, на сервере (назовем его stat) сделано несколько alias:


alias catf='cat flash'
alias cati='cat ip'
alias catp='cat running.prev'
alias catr='cat running.current'
alias catv='cat version'
alias cdr='cd /home/cisco/CONFIG/routers'
alias cds='cd /home/cisco/CONFIG/switches'
alias console='sudo cu -l cuad0 -s 9600'
alias g='grep'
alias h='history'
alias hrcp='rcp running.startup `head -1 ip`:startup-config'
alias hrelo='rsh `head -1 ip` reload'
alias hrent='rcp `head -1 ip`:running-config running.current'
alias hrpw='rcp newpass `head -1 ip`:running-config'
alias l='ls -al'
alias ll='ls -alFG'
alias lsp='less /home/cisco/NOC/pswd'
alias m='more'
alias mc='LANG=en mc'
alias p='ps -ef'
alias phip='ping `head -1 ip`'
alias rhip='rsh `head -1 ip`'
alias ssc='ssh -l cisco `head -1 ip`'
alias tel='telnet'
alias thip='telnet `head -1 ip`'
alias tihp='telnet `head -1 ip`'
alias trace='traceroute -n'


 На маршрутизаторе имеются строки (на stat работа идет из под логина «cisco», в вашем случае имя пользователя может отличаться):


no ip rcmd domain-lookup
ip rcmd rcp-enable
ip rcmd rsh-enable
ip rcmd remote-host cisco stat.example.com cisco enable


 Сбор суточной конфигурации осуществляется этим скриптом. Вывод №2 — в работе необходимо удобство.

 Очень распространена ситуация, когда количество сетевых администраторов в ЦО (не говоря уже про филиалы), явно недостаточно для эффективной работы. В этом случае, хотел бы предостеречь от чрезмерного использования разнообразнейших средств мониторинга и управления. Например, для нормальной работы HP OpenView NNM необходим отдельный человек, который будет постоянно вносить коррективы в схему, управлять раскрытием схемы, группировкой на зоны и т.д. При недостатке сил и средств можно провести разовую настройку, но в дальнейшем система стремительно теряет актуальность. То же самое могу сказать в отношении пакета Cisco Works.

 Оптимальным для себя набором я считаю Cacti(или MRTG), Nagios, кстати, эти два продукта можно заменить Opsview и одно из средств сбора NetFlow.

 Вернемся к нашим филиалам. Для подключения филиалов как по магистральным каналам, так и через Интернет использовался классический DMVPN, это, на данный момент, самая оптимальная технология объединения территориально-распределенных сетей.

 Было принято решение разделить трафик и не загружать магистральные каналы почтовым трафиком и трафиком к/от короративного прокси-сервера. Сделано это было через PBR и Track:

 На стороне ЦО:

!
ip sla Number_SLA
icmp-echo Tunnel_over_Inet source-ip Refl_IP
timeout 1000
threshold 1000
frequency 120
ip sla schedule Number_SLA life forever start-time now
!
!
route-map rm-pbr permit Number_SLA
match ip address acl-pbr-Number_SLA
set ip next-hop verify-availability Brdr_IP 1 track Number_SLA
!
ip access-list extended acl-pbr-Number_SLA
permit ip host Target_Host Branch_Net Wildcard_Branch_Mask
!
track Number_SLA ip sla Number_SLA reachability


• Number_SLA — Номер правила SLA
• Tunnel_over_Inet — IP адрес туннеля в филиале, прокинутого через Интернет
• Refl_IP — IP адрес интерфейса рефлектора, смотрящего на терминирующие маршрутизаторы
• Brdr_IP — IP адрес маршрутизатора, обслуживающего туннели через Интернет
• Target_Host — IP адрес сервер, чей трафик будет пущен через туннель Интернет
• Branch_Net — сеть филиала
• Wildcard_Branch_Mask — wildcard маска сети

 На стороне филиала:


!
ip sla monitor Number_SLA
type echo protocol ipIcmpEcho Tunnel_Hub_IP
timeout 1000
threshold 1000
frequency 180
ip sla monitor schedule 100 life forever start-time now
!
ip route Target_Host 255.255.255.255 Tunnel_Hub_IP track 10
!
track 10 rtr Number_SLA reachability


• Number_SLA — Номер правила SLA
• Tunnel_Hub_IP — IP адрес туннеля маршрутизатора ЦО, через Интернет
• Target_Host — IP адрес сервер, чей трафик будет пущен через туннель Интернет

 В ходе проекта в инфраструктуру сети ЦО были добавлены Cisco ASA 5520, что дало возможность снизить ущерб от вирусных эпидемий и повысить уровень информационной безопасности. Необходимость этого элемента очевидна, в большинстве крупных организаций администраторы ЦО не в состоянии закрыть все бреши в защите филиалов, поэтому уровень доверия к сетям филиалов лишь немногим выше уровня доверия к сети Интернет.

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

 Для примера: при подключении канала Интернет к межсетевому экрану в филиале «Ф» администратор филиала (АФ) предоставил следующие данные:

АФ: К МСЭ подключен интернет через ADSL-модем, статический IP-адрес 195.168.247.17
АЦО: Ок, сообщите пожалуйста адрес, маску подсети и шлюз либо логин/пароль pppoe
АФ: IP-адрес 195.168.247.17 Маска 255.255.255.255 Шлюз 195.168.247.1

 Казалось бы, АФ просто перепутал маску и указал /32 вместо /24, но нет! Ключевая фраза здесь — «через ADSL-модем». Это значит, что модем не переведен в режим bridge и на внешний интрефейс МСЭ необходимо назначить адрес из сети 192.168.1.0/24 (та сеть, что настроена в качестве локальной на модеме).

 Подобных моментов возникает достаточно много.

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

 Не забывайте о разделении обязанностей. Администраторы ЦО, при работе со сложными проектами должны четко расставлять приоритеты и если некую работу может выполнить администратор филиала, то он ее и должен делать, при контроле результата со стороны ЦО.

 Приучите администраторов филиалов проводить первичную диагностику при возникновении проблемы. То есть, это не должен быть звонок «А у меня не работает!», а «А меня нет связи из точки А в точку В, ping до хоста C идет, а до хоста E нет». При этом администраторов филиалов необходимо снабдить таблицами локализации неисправностей.

 В связи с упоминанием Rancid, хотел бы добавить еще два скрипта, работающие в паре с приведенным выше коллектором конфигураций. В результате их работы мы получаем на почту все изменения в конфигурациях за прошедшие сутки. (Учтите, на FreeBSD необходимо использовать GNU Awk):

Diff.sh

#!/bin/sh
#
# This script reports changes founded in Cisco router configurations
# colleted via RSH.
# configurations collected by Cisco robot
#
Dir=`dirname $0`; Script=`basename $0`
Flag=/tmp/.cisco.${Script}; LOG=$Dir/${Script}.log
#
[ -f $Flag ] && exit 0 ; date +"%D %T" > $Flag
trap "rm -rf ${Flag}* $HOME/TMP/*" 0
#
Parser=$Dir/Parse.awk;
Postmaster=`cat $Dir/noc.members`
#
DiffComp()
{
FType=$1; Message=$2
#
for VAR in `ls -1 new_${FType}.* old_${FType}.* 2>/dev/null | cut -d \. -f 2- | sort -u`
do
File=${FType}.$VAR; VAR=`echo $VAR | tr '#!' ' /'`
if [ ! -f new_$File ]; then
printf "\n## $Message $VAR was removed:\n"; cat old_$File
elif [ ! -f old_$File ]; then
printf "\n## $Message $VAR was added:\n"; cat new_$File
else
cmp -s old_$File new_$File && continue
printf "\n## $Message $VAR was changed:\n"
diff -cBw old_$File new_$File | grep '^[-+!] '
fi
done
}
#
for DIR in ${HOME}/CONFIG/routers/* ${HOME}/CONFIG/switches/*
do
cd ${HOME}/TMP; rm -rf *
[ ! -s $DIR/running.current -o ! -r $DIR/running.prev ] && continue
#
$Parser -v AGE=new $DIR/running.current
$Parser -v AGE=old $DIR/running.prev
cmp -s new_total old_total && continue
#
printf "\n@@ Configuration Changes for `basename $DIR` (`head -1 $DIR/ip 2 ${Flag}.log
#
[ ! -s ${Flag}.log ] && exit 0
cat ${Flag}.log | sed -e 's/^\([^@#]\)/ \1/
s/^## / /
s/^@@ / /' | \
mail -s "CISCO Configuration Changes Report" $Postmaster

Parse.awk

#!/usr/local/bin/gawk -f
#!/usr/bin/awk -f
#
BEGIN { IF=AGE "_other.records" }
/^\! Last config/ { next }
/^\! NVRAM / { next }
/^\! No configuration/ { next }
/^ntp clock-period/ { next }
/^username / { $NF="" }
{ print > AGE "_total" }
#
/^access-list [0-9]* / { print > AGE "_acl." $2 ; next }
/^version [0-9]/ { print $2 > AGE "_version" ; next }
/^hostname / { print $2 > AGE "_hostname" ; next }
/^snmp-server/ { print > AGE "_snmp.configuration"; next }
/^x25 route / { print > AGE "_x25.table" ; next }
/^ip route / { print > AGE "_ip.table" ; next }
/^username / { print > AGE "_user." $2 ; next }
#
/^!/ { IF=AGE "_other.records"; next }
#
/^interface/ { IF=AGE "_if." $2; gsub("/","!",IF) }
/^line / { IF=AGE "_line." $2 "#" $3 }
/^router / { IF=AGE "_router." $2 "#" $3 }
/^ipx router / { IF=AGE "_ipxrouter." $3 "#" $4 }
#
{ print > IF }


В файле noc.members перечислены Email администраторов по одному в строке.

Буду дописывать, по мере сил.
17.06.2011

[ad name=»Google Adsense»]

 Уважайте труд автора, сохраняйте копирайты.
Реклама на сайте висит не просто так и если статья Вам понравилась, с ее помощью Вы можете отблагодарить автора за проделанную работу. Спасибо!