Файл: Проектирование маршрутизации в трёх двухуровневых сетях с использованием протокола BGP».pdf
Добавлен: 18.06.2023
Просмотров: 173
Скачиваний: 6
Рисунок 7 Схема передачи данных
Более того, на разных уровнях могут быть разные парадигмы работы. Например, в MPLS Data Plane ориентирован на создание соединения, то есть данные там передаются по заранее определённому пути – LSP.А вот сам этот путь подготавливается по стандартным законам IP – от хоста к хосту. Важно понять назначение уровней и в чём разница. Для BGP это принципиальный вопрос. Когда вы анонсируете свои маршруты, фактически вы создаёте путь для входящего трафика. То есть маршруты исходят от вас, а трафик к вам. Выбор маршрута
Ситуация с маршрутами у нас такая. Есть BGP-таблица, в которой хранятся абсолютно все маршруты, полученные от соседей.
Рисунок 8 пример настройки BGP
То есть если есть у нас несколько маршрутов, до сети 100.0.0.0/23, то все они будут в BGP-таблице, независимо от “плохости” оных: А есть знакомая нам таблица маршрутизации, хранящая только лучшие из лучших. Точно также BGP анонсирует не все приходящие маршруты, а только лучшие. То есть от одного соседа вы никогда не получите два маршрута в одну сеть. Итак, критерии выбора лучших: Максимальное значение Weight (локально для маршрутизатора, только для Cisco)
- Максимальное значение Local Preference (для всей AS)
- Предпочесть локальный маршрут маршрутизатора (next hop = 0.0.0.0)
- Кратчайший путь через автономные системы. (самый короткий AS_PATH)
- Минимальное значение Origin Code (IGP < EGP < incomplete)
- Минимальное значение MED (распространяется между автономными системами)
- Путь eBGP лучше чем путь iBGP
- Выбрать путь через ближайшего IGP-соседа
Если это условие выполнено, то происходит балансировка нагрузки между несколькими равнозначными линками
Следующие условия могут различаться от вендора к вендору. - Выбрать самый старый маршрут для eBGP-пути
- Выбрать путь через соседа с наименьшим BGP router ID
- Выбрать путь через соседа с наименьшим IP-адресом
С выбором маршрутов мы разобрались. Теперь решим пара несколько попутных задач.
И так первая из них :
Условие: Full View на всех маршрутизаторах
Рисунок 9 пример настройки BGP
Это говорит о том, что наш бордер анонсирует чужие маршруты дальше, иными словами наша AS является транзитной.
И тут я нашла два решения
1.
router bgp 64500
no synchronization
bgp log-neighbor-changes
network 100.0.0.0 mask 255.255.254.0
neighbor 101.0.0.1 remote-as 64501
neighbor 101.0.0.1 prefix-list LAN out
neighbor 102.0.0.1 remote-as 64502
neighbor 102.0.0.1 prefix-list LAN out
no auto-summary
!
ip route 100.0.0.0 255.255.254.0 Null0
!
ip prefix-list LAN permit 100.0.0.0/23
2. Настроила при помощи AS-Path ACL:
router bgp 64500
no synchronization
bgp log-neighbor-changes
network 100.0.0.0 mask 255.255.254.0
network 100.0.0.0 mask 255.255.255.0
network 100.0.1.0 mask 255.255.255.0
neighbor 101.0.0.1 remote-as 64501
neighbor 101.0.0.1 filter-list 100 out
neighbor 102.0.0.1 remote-as 64502
neighbor 102.0.0.1 filter-list 100 out
no auto-summary
!
ip route 100.0.0.0 255.255.254.0 Null0
ip route 100.0.0.0 255.255.255.0 Null0
ip route 100.0.1.0 255.255.255.0 Null0
!
ip as-path access-list 100 permit ^$
И задача номер два:
Задание: Настроить маршрутизацию таким образом, чтобы HTTP-трафик из локальной сети 10.0.1.0 шел через одного провайдера, а весь трафик из сети 10.0.2.0 через второго. Если в адресе отправителя фигурирует любой другой адрес, трафик должен быть отброшен, а не маршрутизироваться по стандартной таблице маршрутизации
Обычно, работу IP SLA рассматривают на простейшем примере icmp-echo. То есть, в случае, если мы можем пинговать тот конец линии, трафик идет по ней, если не можем – по другой. Но мы пойдем путем чуть посложнее. Итак, нас интересуют характеристики канала, важные для голосового трафика, например, джиттер. Конкретнее, udp-jitter, поэтому пишем
R4(config-ip-sla)#udp-jitter 192.168.200.1 55555
В этой команде после указания вида проверки (udp-jitter) идет ip адрес, куда будут отсылаться пробы (т.е. меряем от нас до 192.168.200.1 – это лупбек на R1) и порт (от балды 55555). Затем можно настроить частоту проверок (по умолчанию 60 секунд):
R4(config-ip-sla-jitter)#frequency 10
и предельное значение, при превышении которого объект ip sla 1 рапортует о недоступности:
R4(config-ip-sla-jitter)#threshold 10
Некоторые виды измерений в IP SLA требуют наличия “на той стороне” так называемого “ответчика” (responder), некоторые (например, FTP, HTTP, DHCP, DNS) нет. Наш udp-jitter требует, поэтому, прежде чем запускать измерения, нужно подготовить R1:
R1(config)#ip sla responder
Теперь нам нужно запустить сбор статистики. Командуем
R4(config)#ip sla schedule 1 start-time now life forever
Т.е. запускаем объект мониторинга 1 прямо сейчас и до конца дней.
Мы не можем менять параметры объекта, если запущен сбор статистики. Т.е. чтобы поменять, например, частоту проб, нам нужно сначала выключить сбор информации с него: no ip sla schedule 1
Теперь уже можем посмотреть, что у нас там собирается:R4#sh ip sla statistics 1Round Trip Time (RTT) for Index 1Latest RTT: 36 milliseconds Latest operation start time: *00:39:01.531 UTC Fri Mar 1 2002Latest operation return code: OKRTT Values:Number Of RTT: 10 RTT Min/Avg/Max: 19/36/52 millisecondsLatency one-way time:Number of Latency one-way Samples: 0 Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
Number of SD Jitter Samples: 9
Number of DS Jitter Samples: 9
Source to Destination Jitter Min/Avg/Max: 0/5/20 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/16/28 milliseconds
Packet Loss Values:
Loss Source to Destination: 0 Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 0
Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 0
Mean Opinion Score (MOS): 0
Number of successes: 12
Number of failures: 0
Operation time to live: Forever
а также что мы там на конфигурировали
R4#sh ip sla conf
IP SLAs Infrastructure Engine-II
Entry number: 1
Owner:
Tag:
Type of operation to perform: udp-jitter
Target address/Source address: 192.168.200.1/0.0.0.0
Target port/Source port: 55555/0
Request size (ARR data portion): 32
Operation timeout (milliseconds): 5000
Packet Interval (milliseconds)/Number of packets: 20/10
Type Of Service parameters: 0x0
Verify data: No
Vrf Name:
Control Packets: enabled
Schedule:
Operation frequency (seconds): 10 (not considered if randomly scheduled)
Next Scheduled Start Time: Pending trigger
Group Scheduled: FALSE
Randomly Scheduled: FALSE
Life (seconds): 3600
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 10
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 4294967295
Enhanced History:
Теперь настраиваем так называемый track (неправильный, но понятный перевод “отслеживатель”). Именно к его состоянию привязываются впоследствии действия в роут-мапе. В track можно выставить задержку переключения между состояниями, что позволяет решить проблему, когда у нас по одной неудачной пробе меняется маршрутизация, а по следующей, уже удачной, меняется обратно. Указываем номер track и к какому номеру объекта ip sla мы его подключаем (rtr 1):R4(config)#track 1 rtr 1
Настраиваем задержку: R4(config-track)#delay up 10 down 15
Это означает: если объект мониторинга упал и не поднялся в течение 15 секунд, переводим track в состояние down. Если объект был в состоянии down, но поднялся и находится в поднятом состоянии хотя бы 10 секунд, переводим track в состояние up.
Следующим действием нам нужно привязать track к нашей роут-мапе. Напомню, стандартный путь от R5 к R1 идет через R2, но у нас имеется роут-мапа BACK, переназначающая стандартное положение вещей в случае, если источник R5:
R4#sh run | sec route-map
ip policy route-map BACK
route-map BACK permit 10
match ip address 100
set ip next-hop 192.168.3.3
Если мы привяжем наш мониторинг к этой мапе, заменив команду set ip next-hop 192.168.3.3 на set ip next-hop verify-availability 192.168.3.3 10 track 1, получим обратный нужному эффект: в случае падения трека (из-за превышения показателя джиттера в sla 1), мапа не будет отрабатываться (все будет идти согласно таблице маршрутизации), и наоборот, в случае нормальных значений, трек будет up, и трафик будет идти через R3.
Как это работает: роутер видит, что пакет подпадает под условия match, но потом не сразу делает set, как в предыдущем примере с PBR, а промежуточным действием проверяет сначала состояние трека 1, а затем, если он поднят (up), уже делается set, если нет – переходит к следующей строчке роут-мапы.
Для того, чтобы наша мапа заработала, как надо, нам нужно как-то инвертировать значение трека, т.е. когда джиттер большой, наш трек должен быть UP, и наоборот. В этом нам поможет такая штука, как track list. В IP SLA существует возможность объединять в треке список других треков (которые, по сути, выдают на выходе 1 или 0) и производить над ними логические операции OR или AND, а результатом этих операций будет состояние этого трека. Кроме этого, мы можем применить логическое отрицание к состоянию трека. Создаем трек-лист:
R4(config)#track 2 list boolean or
Единственным в этом “списке” будет логическое отрицание значения трека 1:
R4(config-track)#object 1 not
Теперь привязываем роут-мап к этому треку
R4(config)#route-map BACK
R4(config-route-map)#no set ip next-hop 192.168.3.3
R4(config-route-map)#set ip next-hop verify-availability 192.168.3.3 10 tr 2
Цифра 10 после адреса некстхопа – это его порядковый номер (sequence number). Мы можем, к примеру, использовать его так:
route-map BACK permit 10
match ip address 100
set ip next-hop verify-availability 192.168.3.3 10 track 1
set ip next-hop verify-availability 192.168.2.2 20 track 2
Тут такая логика: выбираем трафик, подпадающий под ACL 100, затем идет промежуточная проверка track 1, если он up, ставим пакету некстхоп 192.168.3.3, если down, переходим к следующему порядковому номеру (20 в данном случае), опять же промежуточно проверяем состояние трека (уже другого, 2), в зависимости от результата, ставим некстхоп 192.168.2.2 или отправляем с миром (маршрутизироваться на общих основаниях).
Давайте теперь немножко словами порассуждаем, что же мы такое накрутили: итак, измерения джиттера у нас идут от источника R4 к респондеру R1 по маршруту через R2. Максимальное допустимое значение джиттера на этом маршруте у нас – 10. В случае, если джиттер превышает это значение и держится на этом уровне 15 секунд, мы переключаем трафик, генерируемый R5, на маршрут через R3. Если джиттер падает ниже 10 и держится там минимум 10 секунд, пускаем трафик от R5 по стандартному маршруту. Попробуйте для закрепления материала найти, в каких командах задаются все эти значения.
Итак, мы достигли цели: теперь, в случае ухудшения качества основного канала (ну, по крайней мере, значений udp-джиттера), мы переходим на резервный. Но что, если и там тоже не очень? Может, попробуем с помощью IP SLA решить и эту проблему?
Попробуем выстроить логику того, что мы хотим сделать. Мы хотим перед переключением на резервный канал проверять, как у нас обстоит дело с джиттером на нем. Для этого нам нужно завести дополнительный объект мониторинга, который будет считать джиттер на пути R4-R3-R1, пусть это будет 2. Сделаем его аналогичным первому, с теми же значениями. Условием переключения на резервный канал тогда будет: объект 1 down И объект 2 up. Чтобы измерять джиттер не по основному каналу, придется пойти на хитрость: сделать loopback-интерфейсы на R1 и R4, прописать статические маршруты через R3 туда-обратно, и использовать эти адреса для объекта SLA 2.
R1(config)#int lo1
R1(config-if)#ip add 192.168.30.1 255.255.255.0
R1(config-if)#exit
R1(config)#ip route 192.168.31.0 255.255.255.0 192.168.1.3
R3(config)#ip route 192.168.30.0 255.255.255.0 192.168.1.1
R3(config)#ip route 192.168.31.0 255.255.255.0 192.168.3.4
R4(config)#int lo0
R4(config-if)#ip add 192.168.31.4 255.255.255.0
R4(config-ip-sla-jitter)#exit
R4(config)#ip sla 2
R4(config-ip-sla)#udp-jitter 192.168.30.1 55555 source-ip 192.168.31.4
R4(config-ip-sla-jitter)#threshold 10
R4(config-ip-sla-jitter)#frequency 10
R4(config-ip-sla-jitter)#exit
R4(config)#ip route 192.168.30.0 255.255.255.0 192.168.3.3
R4(config)#ip sla schedule 2 start-time now life forever
R4(config)#track 3 rtr 2
Теперь меняем условие трека 2, к которому привязана роут-мапа:R4(config)#track 2 list boolean andR4(config-track)#object 1 notR4(config-track)#object 3
Теперь трафик R5->R1 переключается на запасной маршрут только в том случае, если джиттер основного канала больше 10 и, в это же время, джиттер запасного меньше 10. В случае, если высокий джиттер наблюдается на обоих каналах, трафик идет по основному и молча страдает.
Состояние трека можно привязать также к статическому маршруту: например, мы можем командой ip route 0.0.0.0 0.0.0.0 192.168.1.1 track 1 сделать шлюзом по умолчанию 192.168.1.1, который будет связан с треком 1 (который, в свою очередь, может проверять наличие этого самого 192.168.1.1 в сети или измерять какие-нибудь важные характеристики качества связи с ним). В случае, если связанный трек падает, маршрут убирается из таблицы маршрутизации.
Также будет полезным упомянуть, что информацию, получаемую через IP SLA, можно вытащить через SNMP, чтобы потом можно было ее хранить и анализировать где-нибудь в вашей системе мониторинга. Можно даже настроить SNMP-traps.
ЗАКЛЮЧЕНИЕ
На данный момент было решено три важные задачи: по выбору маршрутов, маршрутизаторы провайдеров также не используют BGP и Full View на всех маршрутизаторах. Так же еще осталось куча не решенных задач и огромный простор для модернизации сети. Для модернизации сети можно будет использовать прокол OSPF внутри сети.
Список использованной литературы
- . Олифер, В. Г. Компьютерные сети. Принципы, технологии, протоколы: учебник для вузов. 4-е изд./В.Г. Олифер, Н. А. Олифер.— Санкт-Петербург: Питер, 2010. — 944 с.: ил.
- Таненбаум, Э., Компьютерные сети. 5-е изд./ Э. Таненбаум, Д. Уэзерхолл— Санкт-Петербург.: Питер, 2016. — 960 с.: ил.
- Палмер, М. Проектирование и внедрение компьютерных сетей/ М. Палмер, Р.Б. Синклер — Санкт-Петербург: БХВ-Петербург, 2007. — 740 с.: ил.
- Петерсен, Р. Энциклопедия Linux. Наиболее полное и подробное руководство/Р. Петерсен — Санкт-Петербург: БХВ-Петербург, 2012. — 675 с.: ил.
- Грегор Н. Парди, LINUX руководство администратора сети / Грегор Н. Парди — Москва: КУДИЦ-Пресс, 2008. — 368 с.: ил.
- Шаньгин, В. Информационная безопасность компьютерных систем и сетей / В. Шаньгин — Москва: Форум, 2011. — 416 с.: ил.
- Грушко, А. Теоретические основы компьютерной безопасности / А. Грушко — Москва: Academia, 2009. — 272 с.: ил.
- Павлюк, В.Д. Типовые топологии вычислительных сетей / В.Д. Павлюк — Москва: Форум, 2012. — 488 с.: ил.
- Минаев, И.Я. Локальная сеть своими руками / И.Я. Минаев – Москва: Феникс, 2009. – 367 с.: ил.
- Сергеев, А.П. Офисные локальные сети. Самоучитель / А.П. Сергеев – Москва: Academia, 2010. – 320 с.: ил.
- Максимов, Н.В. Компьютерные сети/ Н.В. Максимов, И.И. Попов – Санкт-Петербург: Питер, 2009. – 464 с.: ил.
- Кенин, А.М. Практическое руководство системного администратора. 2-е изд. / А.М. Кенин — Санкт-Петербург: БХВ-Петербург, 2013. — 544 с.: ил.
- Мэйволд, Э. Безопасность сетей. 2-е изд. / Э. Мейволд – Москва: ПрофИздат, 2016. – 572 с.: ил.
- Бройдо, В.Л. Вычислительные системы, сети и телекоммуникации. 4-е изд./ В.Л. Бройдо, О.П. Ильина – Москва: Феникс, 2011. – 560 с.: ил. 16. Кенин, А.М. Самоучитель системного администратора. 3-е изд. / А.М. Кенин — Санкт-Петербург: БХВ-Петербург, 2012. — 512 с.: ил.
- Пескова, С.А. Сети и телекоммуникации. 3-е изд./ С.А. Пескова, А.В. Кузин, А.Н. Волков — Москва: Форум, 2008. — 354 с.: ил.
- Алиев, Т.И. Сети ЭВМ и телекоммуникации / Т.И. Алиев – Москва: ПрофИздат, 2011. – 399 с.: ил.
- Кузин, А.В. Компьютерные сети. Учебное пособие / А.В. Кузин – Москва: Academia, 2011. – 192 с.: ил.
- Степанов, С.Н. Основы телетрафика мультисервисных сетей / С.Н. Степанов – Санкт-Петербург: Питер, 2010. – 392 с.: ил.
- Методические рекомендации по оформлению выпускных квалификационных работ, курсовых проектов/работ для очной, очно-заочной (вечерней) и заочной форм обучения. – Вологда: ВоГУ, 2016. – 103 с.
- Электроэнергетика и электротехника. Информатика и вычислительная техника. Методическое пособие по оформлению текстовых и графических документов / сост.: Н. Н. Черняева. – Вологда: ВоГУ, 2016. –101 с.