Модернизация сети филиалов

Опубликовано 16.05.2011

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

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

  • Имеется 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»]



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

13 комментариев в Модернизация сети филиалов

  1. 1. Админ филиала должен настраивать свое оборудование сам. Ибо в случае проблем в филиале по голове будет получать именно админ филиала, и никому будет не интересно, что циску филиала настроил админ ЦО, а админ филиала даже не знает что-такое циска и всю предыдущую жизнь пользовался линухом или виндой.
    2. очень хорошо, что админ ЦО заботится о вирусной безопасности со стороны филиалов. Но возможна ситуация, когда нужно защищать филиалы от вирусов из ЦО. Однако, обычно, доступ в филиалы из ЦО делают полным, а из филиалов в ЦО — только по талонам.
    3. Статья основывается на Московском взгляде на окружающий мир. «Я в Москве — поэтому я намного умнее». Даже чисто арифметически звучит коряво, один админ из Москвы умнее семидесяти админов из филиалов.
    4. это вкратце

  2. 1. Нет. Если оборудование настраивает местный специалист, то при 130 филиалах Вы получите 130 различных конфигураций. Руководство IT располагается в ЦО и впервую очередь прилетит плюха администратору ЦО. Тем более, при черезвычайно низких зарплатах в филиалах найти администратора, способного настроить оборудование достаточно сложно.

    2. Согласен, именно поэтому мы фильтруем в обе стороны.

    3. Я родился и прожил большую часть жизни не в Москве. И в Москву я езжу только на работу, являясь типичным «замкадышем». У меня есть опыт, который Вы можете принимать или нет. Но основании этого опыта я и даю некие тезисы.

  3. Автор прав на 100%. От себя лишь добавлю что обязательно надо регулярно посещать филиалы, иначе там будет дурдом — из ssh или rdp не всё разглядеть можно. Там где я когда-то работал, умельцы из китайского филиала вытащили DVD-RW привод из местного сервера и заменили его ломаным приводом CD-ROM — когда я туда прибыл, долго не мог понять почему HP SmartStart CD глючит. А испанские тореадоры питали серверную электричеством через длинный удлинитель который подключили в один из кубиков openspace — не трудно догадаться что удлинитель иногда отключали, наверное очень мешал. Урок: вне зависимости от местонахождения, все филиалы надо обязательно посещать как минимум раз в год.

  4. 130 различных конфигураций — это несомненно плохо.
    Но! Сколько потребуется времени и денег что бы восстановить связь с филиалом при выходе из строя циски, настроенной в Москве? Купить (хорошо если уже есть резервная), настроить, доставить в филиал. Не лучше ли будет если админ филиала не просто меняет картриджы в филиале, но еще может самостоятельно разобраться со своими проблемами?
    Кроме того, если админу в филиале не давать работать с техникой, то ваши анекдоты о тупых админах из провинции станут повсеместной реальностью. А хотите я такие же байки расскажу о админах из ЦО?
    Теперь с точки зрения руководителя: увольнение админа ЦО, настроившего все филиалы, может привести к очень серьезным рискам. Однако, если каждый филиал настраивал свою сеть сам — проблемы локализуются только в ЦО.
    Нормальное развитие организации с филиальной сетью невозможно только за счет развития ЦО. Ведь возможна ситуация, когда портрет админа ЦО будет вывешен в красном углу филиала, а утро будет начинаться с молитвы о даровании качественной связи «Админ наш великий, даруй связь нам без лагов и вирусов безвредных!…»
    Я родился и прожил всю жизнь не в Москве. И в Москву я езжу только что бы перенять передовой опыт коллег из ЦО. У меня есть опыт, который Вы можете принимать или нет. Видимо по Вашей градации филиальных админов я отношусь к сепаратистам 🙂

  5. 14.06.2011 — Вы из будущего?

    Статья дала смешанные чувства. С одной стороны подход к администраторам филиалов верный — они должны быть партнерами в общении, а не подчиненными, и в случае возникающих проблем у них не должно возникать чувство, что их бросили на произвол — «решайте проблему как хотите».

    С другой стороны использовать rsh/rsc в наш прогрессивный XXI век?! Где же ssh/scp?

    Из своего опыта в этой области могу добавить, что наличие какой-либо централизованной системы базы знаний — KB, wiki, общий свод правил IT с описанием инфраструктуры — очень хорошо помогает обобщать и локализировать проблему. Нужно приучать также администраторов пользоваться ресурсом и пополнять его. Можно пойти дальше и создать нечто социальной среды для общения.

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

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

    По моему, причина желания руления всем и вся из ЦО достаточно понятна.

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

    Я остановился на zabbix 🙂

  8. >14.06.2011 – Вы из будущего?

    Я так умумукался в последнее время, что начал путать месяцы 🙁 В результате такой путанницы на месяц перенеслась командировка в Уфу 🙂

    >Но! Сколько потребуется времени и денег что бы восстановить связь с филиалом при выходе из строя циски, настроенной в Москве? Купить (хорошо если уже есть резервная), настроить, доставить в филиал.

    Тут два момента: если из строя выходит что-то дорогое (на что денег у филиала нет), типа 2851, то всё равно придется заказывать поставку из Москвы и времени будет потрачено одинаково. Если из строя вышел маршрутизатор миниофиса — 871 и т.п., то он вешается на консоль маршрутизатора филиала и туда вливается резервная/новая конфигурация.

    >Ведь возможна ситуация, когда портрет админа ЦО будет вывешен в красном углу филиала, а утро будет начинаться с молитвы о даровании качественной связи «Админ наш великий, даруй связь нам без лагов и вирусов безвредных!…»

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

    >Не лучше ли будет если админ филиала не просто меняет картриджы в филиале, но еще может самостоятельно разобраться со своими проблемами?

    Лучше, намного лучше. Но! Вы, я думаю, представляете уровень оплаты труда в регионах. Для примера, начальник отдела IT в Саратовском филиале одного банка получает порядка 25 тысяч рублей. Это отвратительно мало, но влиять на это нет никакой возможности, поэтому с этим можно только смириться. И тут есть два пути — учить администраторов филиалов, превращаясь в кузницу кадров для других контор или централизировать управление.

    >Из своего опыта в этой области могу добавить, что наличие какой-либо централизованной системы базы знаний – KB, wiki, общий свод правил IT с описанием инфраструктуры – очень хорошо помогает обобщать и локализировать проблему. Нужно приучать также администраторов пользоваться ресурсом и пополнять его. Можно пойти дальше и создать нечто социальной среды для общения.

    Да, полностью согласен! Надо будет думать, как такое организовать и приучить людей этим пользоваться.

  9. Действительно, очень хорошая статья.
    Сам последние 2,5 года работал админом в филиале, многое могу подтвердить.
    Великолепно, когда отношения админов Головного офиса и филиалов строятся не по принципу «я начальник — ты дурак», а на каких-то партнёрских моментах.
    Но учить АФ в любом случае нужно, и тут пример с кузницей кадров не подходит.
    Иначе будут уходить туда, где есть возможность повысить квалификацию, а не только менять картриджи.
    В общем материалу однозначно большой и жирный плюс 🙂

  10. >Для примера, начальник отдела IT в Саратовском филиале одного банка получает порядка 25 тысяч рублей. Это отвратительно мало, но влиять на это нет никакой возможности, поэтому с этим можно только смириться.

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

  11. Я полностью согласен, но это данность, с которой необходимо сосуществовать. На персонал денег выделяют мало. Хозяин конторы не разбирается в частных случаях, он видит итоговую сумму расходов и ФОТ в них может занимать значительную часть.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

*