Файл: Проектирование маршрутизации в трёх двухуровневых сетях с использованием протокола BGP».pdf

Рисунок 7 Схема передачи данных

Более того, на разных уровнях могут быть разные парадигмы работы. Например, в MPLS Data Plane ориентирован на создание соединения, то есть данные там передаются по заранее определённому пути – LSP.А вот сам этот путь подготавливается по стандартным законам IP – от хоста к хосту. Важно понять назначение уровней и в чём разница. Для BGP это принципиальный вопрос. Когда вы анонсируете свои маршруты, фактически вы создаёте путь для входящего трафика. То есть маршруты исходят от вас, а трафик к вам. Выбор маршрута

Ситуация с маршрутами у нас такая. Есть BGP-таблица, в которой хранятся абсолютно все маршруты, полученные от соседей. 

Рисунок 8 пример настройки BGP

То есть если есть у нас несколько маршрутов, до сети 100.0.0.0/23, то все они будут в BGP-таблице, независимо от “плохости” оных: А есть знакомая нам таблица маршрутизации, хранящая только лучшие из лучших. Точно также BGP анонсирует не все приходящие маршруты, а только лучшие. То есть от одного соседа вы никогда не получите два маршрута в одну сеть. Итак, критерии выбора лучших: Максимальное значение Weight (локально для маршрутизатора, только для Cisco)

1. Максимальное значение Local Preference (для всей AS)
2. Предпочесть локальный маршрут маршрутизатора (next hop = 0.0.0.0)
3. Кратчайший путь через автономные системы. (самый короткий AS_PATH)
4. Минимальное значение Origin Code (IGP < EGP < incomplete)
5. Минимальное значение MED (распространяется между автономными системами)
6. Путь eBGP лучше чем путь iBGP
7. Выбрать путь через ближайшего IGP-соседа
   Если это условие выполнено, то происходит балансировка нагрузки между несколькими равнозначными линками
   Следующие условия могут различаться от вендора к вендору.
8. Выбрать самый старый маршрут для eBGP-пути
9. Выбрать путь через соседа с наименьшим BGP router ID
10. Выбрать путь через соседа с наименьшим 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 внутри сети.

Список использованной литературы

1. . Олифер, В. Г. Компьютерные сети. Принципы, технологии, протоколы: учебник для вузов. 4-е изд./В.Г. Олифер, Н. А. Олифер.— Санкт-Петербург: Питер, 2010. — 944 с.: ил.
2. Таненбаум, Э., Компьютерные сети. 5-е изд./ Э. Таненбаум, Д. Уэзерхолл— Санкт-Петербург.: Питер, 2016. — 960 с.: ил.
3. Палмер, М. Проектирование и внедрение компьютерных сетей/ М. Палмер, Р.Б. Синклер — Санкт-Петербург: БХВ-Петербург, 2007. — 740 с.: ил.
4. Петерсен, Р. Энциклопедия Linux. Наиболее полное и подробное руководство/Р. Петерсен — Санкт-Петербург: БХВ-Петербург, 2012. — 675 с.: ил.
5. Грегор Н. Парди, LINUX руководство администратора сети / Грегор Н. Парди — Москва: КУДИЦ-Пресс, 2008. — 368 с.: ил.
6. Шаньгин, В. Информационная безопасность компьютерных систем и сетей / В. Шаньгин — Москва: Форум, 2011. — 416 с.: ил.
7. Грушко, А. Теоретические основы компьютерной безопасности / А. Грушко — Москва: Academia, 2009. — 272 с.: ил.
8. Павлюк, В.Д. Типовые топологии вычислительных сетей / В.Д. Павлюк — Москва: Форум, 2012. — 488 с.: ил.
9. Минаев, И.Я. Локальная сеть своими руками / И.Я. Минаев – Москва: Феникс, 2009. – 367 с.: ил.
10. Сергеев, А.П. Офисные локальные сети. Самоучитель / А.П. Сергеев – Москва: Academia, 2010. – 320 с.: ил.
11. Максимов, Н.В. Компьютерные сети/ Н.В. Максимов, И.И. Попов – Санкт-Петербург: Питер, 2009. – 464 с.: ил.
12. Кенин, А.М. Практическое руководство системного администратора. 2-е изд. / А.М. Кенин — Санкт-Петербург: БХВ-Петербург, 2013. — 544 с.: ил.
13. Мэйволд, Э. Безопасность сетей. 2-е изд. / Э. Мейволд – Москва: ПрофИздат, 2016. – 572 с.: ил.
14. Бройдо, В.Л. Вычислительные системы, сети и телекоммуникации. 4-е изд./ В.Л. Бройдо, О.П. Ильина – Москва: Феникс, 2011. – 560 с.: ил. 16. Кенин, А.М. Самоучитель системного администратора. 3-е изд. / А.М. Кенин — Санкт-Петербург: БХВ-Петербург, 2012. — 512 с.: ил.
15. Пескова, С.А. Сети и телекоммуникации. 3-е изд./ С.А. Пескова, А.В. Кузин, А.Н. Волков — Москва: Форум, 2008. — 354 с.: ил.
16. Алиев, Т.И. Сети ЭВМ и телекоммуникации / Т.И. Алиев – Москва: ПрофИздат, 2011. – 399 с.: ил.
17. Кузин, А.В. Компьютерные сети. Учебное пособие / А.В. Кузин – Москва: Academia, 2011. – 192 с.: ил.
18. Степанов, С.Н. Основы телетрафика мультисервисных сетей / С.Н. Степанов – Санкт-Петербург: Питер, 2010. – 392 с.: ил.
19. Методические рекомендации по оформлению выпускных квалификационных работ, курсовых проектов/работ для очной, очно-заочной (вечерней) и заочной форм обучения. – Вологда: ВоГУ, 2016. – 103 с.
20. Электроэнергетика и электротехника. Информатика и вычислительная техника. Методическое пособие по оформлению текстовых и графических документов / сост.: Н. Н. Черняева. – Вологда: ВоГУ, 2016. –101 с.

---