Допустим у нас появилось 2 клиента, которым нужен большой пул адресов. Пусть мы выделим им подсети 200.0.0.0/25 и 200.0.0.128/25. Для этого можно просто навесить эти адреса на любой интерфейс на любые юниты и включить их в OSPF как passive. Сделаем это на RT.SPB.MIR:
Далее создаём политику по редистрибуции этих маршрутов в BGP:
root@RT.SPB.MIR# show | compare
[edit protocols bgp]
+ export ospf-export;
[edit policy-options]
+ policy-statement ospf-export {
+ term area-200.0.0.0 {
+ from {
+ protocol ospf;
+ area 200.0.0.0;
+ }
+ }
+ term area-200.0.0.128 {
+ from {
+ protocol ospf;
+ area 200.0.0.128;
+ }
+ }
+ then accept;
+ }
Маршруты с указанных областей будут попадать в BGP-таблицу, но отправятся они только будут только соседям. Т.е. BGP-маршрут отправится только трём соседям, указанным в конфигурации RT.SPB.MIR. Внутри Sub-AS 65003 маршрут будет распространяться нормально, но вот Route Reflector´ы маршрут, полученный по BGP распространять далее не будут, так как у них есть More Specific Route полученный по OSPF. Что с этим можно сделать? Можно указать на всех роутерах атрибут, который позволит распространять даже неактивные маршруты:
Вот какие префиксы мы анонсируем K12:
root@RT.SPB.LNX# run show route advertising-protocol bgp 10.0.0.203
inet.0: 46 destinations, 86 routes (46 active, 0 holddown, 3 hidden)
Prefix Nexthop MED Lclpref AS path
* 8.0.0.0/16 10.1.1.200 100 (65001) 8000 I
* 100.0.0.0/24 10.1.1.200 100 (65001) 8000 I
* 192.168.88.0/24 10.0.0.202 100 I
Вводим соответствующую команду и получаем результат:
root@RT.SPB.LNX# set protocols bgp advertise-inactive
root@RT.SPB.OBV# set protocols bgp advertise-inactive
Маршрут попадёт в Hidden из-за нашей политики, которая не позволяет принимать префиксы длиннее 24:
root@RT.SPB.K12# run show route hidden 200.0.0.0 detail
inet.0: 48 destinations, 73 routes (47 active, 0 holddown, 21 hidden)
200.0.0.0/25 (2 entries, 1 announced)
BGP /-101
Next hop type: Indirect
Address: 0x9638ba4
Next-hop reference count: 8
Source: 10.0.0.201
Next hop type: Router, Next hop index: 566
Next hop: 10.0.0.15 via ae1.0, selected
Session Id: 0x143
Protocol next hop: 10.0.0.202
Indirect next hop: 0x96c8330 - INH Session ID: 0x0
State: <Hidden Int Ext>
Inactive reason: Unusable path
Local AS: 65002 Peer AS: 65002
Age: 2:53 Metric2: 2
Validation State: unverified
Task: BGP_65002.10.0.0.201+179
AS path: I (Originator)
Cluster list: 10.0.0.201
Originator ID: 10.0.0.202
Localpref: 100
Router ID: 10.0.0.201
Hidden reason: rejected by import policy
Что можно сделать? Можно либо поменять политики, либо прописать статический маршрут, либо сагрегировать маршруты, что мы и сделаем.
Aggregate Routes
Агрегированные маршруты позволяют без лишних опций сконфигрурировать Less Specific Route для нескольких маршрутов, чтобы передать его по BGP. Агрегированный маршрут будет активен (и как следствие передаваться по BGP) только если у него будут Contribute (More Specific) Routes. Предыдущий конфиг редистрибуции маршрутов можно удалить c RT.SPB.MIR. Добавим агрегированный маршрут, экспортируем его в таблицу BGP атрибут advertise-inactive не потребуется ни на одном из роутеров, так как маршрут будет активным:
root@RT.SPB.MIR# show | compare
[edit routing-options]
+ aggregate {
+ route 200.0.0.0/24;
+ }
[edit protocols bgp]
- export ospf-export;
+ export aggregate-export;
[edit policy-options]
+ policy-statement aggregate-export {
+ from {
+ protocol aggregate;
+ route-filter 200.0.0.0/24 exact;
+ }
+ then accept;
+ }
- policy-statement ospf-export {
- term area-200.0.0.0 {
- from {
- protocol ospf;
- area 200.0.0.0;
- }
- }
- term area-200.0.0.128 {
- from {
- protocol ospf;
- area 200.0.0.128;
- }
- }
- then accept;
- }
Также можно сагрегировать маршруты так, чтобы мы анонсировали contribute routes (More Specific) для Aggregate маршрута, а не сам Aggregate Route, при помощи команды:
set policy-options policy-statement name from aggregate-contributor x.x.x.x/x
Как видно, всё в порядке:
root@AS8000> show route 200.0.0.0
inet.0: 16 destinations, 23 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.0.0.0/24 *[BGP/170] 00:07:33, localpref 100
AS path: 9000 I, validation-state: unverified
> to 8.0.0.3 via ge-0/0/1.0
[BGP/170] 00:07:33, localpref 100
AS path: 9000 I, validation-state: unverified
> to 8.0.0.1 via ge-0/0/4.0
Generate Route
Данный маршрут ничем не отличсается от Aggregate, кроме того, что Next-Hop у него не равен Reject или Discard, а равен он Next-Hop'у одного из Contribute Routes. Используется провайдерами, в основном для установки маршурта 0.0.0.0/0 и передачи его каким-нибудь клиентам.
Допустим, нам необходимо сгенерировать маршрут 0.0.0.0/0 для клиентов, которые берут у нас IP-транзит и не хотят получать Full-View или хотят получать Full-View + Defaul Route. Можно прописать статический маршрут с кучей next-hop адресов, а можно просто прописать Generate Route, указав, что в него мы включим только Contribute Routes от наших аплинков. Т.е. через Policy-Option мы просто запретим попадание наших подсетей, как Contribute Routes для маршрута 0.0.0.0/0.
Прежде всего перенастроим OSPF: удалим все Area и включим все наши линки в Area 0, чтобы не было никаких проблем с маршрутом 0.0.0.0/0, который экспортируется в OSPF на RT.SPB.MIR и который передаётся ABR в stub-areas.
Далее добавим на каждый роутер, у которого есть eBGP-пир, Generate Route 0.0.0.0/0, оставив в Contribute Routes только сети аплинков. Запретим, например, попадание сети 40.0.0.0/8 (предположим, что это наш пул) в которую входит клиентская сеть 40.0.0.0/24. Почему добавляем на каждый роутер с eBGP-пирами? Если Generate Route будет настроен только на одном роутере, и он упадёт, то маршрут просто исчезнет.
Пример настройки на RT.MSK.M34:
root@RT.MSK.M34# show | compare
[edit routing-options]
+ generate {
+ route 0.0.0.0/0 policy Contributes_For_Gateway;
+ }
[edit policy-options]
+ policy-statement Contributes_For_Gateway {
+ term 1 {
+ from {
+ route-filter 40.0.0.0/8 orlonger;
+ }
+ then reject;
+ }
+ term 2 {
+ from {
+ protocol bgp;
+ route-type external;
+ }
+ then accept;
+ }
+ then reject;
+ }
+ policy-statement Gateway_to_iBGP {
+ from {
+ protocol aggregate;
+ route-filter 0.0.0.0/0 exact;
+ }
+ then accept;
+ }
[edit protocols bgp group intra-Sub-AS]
- export next-hop-self;
+ export [ next-hop-self Gateway_to_iBGP ];
Что же мы видим теперь на маршрутизаторах:
root@RT.MSK.M34# run show route 0.0.0.0 protocol aggregate extensive
inet.0: 46 destinations, 53 routes (45 active, 0 holddown, 1 hidden)
0.0.0.0/0 (2 entries, 1 announced)
TSI:
KRT in-kernel 0.0.0.0/0 -> {8.0.0.2}
Page 0 idx 1, (group intra-Sub-AS type Internal) Type 1 val 0x95a6ac4 (adv_entry)
Advertised metrics:
Nexthop: 8.0.0.2
Localpref: 100
AS path: [65001] I
Communities:
Path 0.0.0.0 Vector len 4. Val: 1
*Aggregate Preference: 130
Next hop type: Router, Next hop index: 561
Address: 0x96383a0
Next-hop reference count: 18
Next hop: 8.0.0.2 via ge-0/0/1.0, selected
Session Id: 0x140
State: <Active Int Ext>
Local AS: 65001
Age: 1:15:02
Validation State: unverified
Task: Aggregate
Announcement bits (3): 0-KRT 4-BGP_RT_Background 5-Resolve tree 1
AS path: I
Flags: Generate Depth: 0 Active
Contributing Routes (4):
8.0.0.0/16 proto BGP
8.1.0.0/16 proto BGP
100.0.0.0/24 proto BGP
101.0.0.0/24 proto BGP
Т.е. у нас имеется маршурт по умолчанию, next-hop, которого автоматически подстраивается под текущую ситуацию на сети. И чем больше у нас аплинков, тем больше у нас Nex-Hop адресов, на которые мы сможем отправить трафик. При этом с нашей стороны для этого не потребуется ничего делать. Всё будет происходить согласно Policy-Option.
А теперь предположим, что мы хотим послать запрос на неизвестный нам IP от клиента. Предварительно отключим интерфейсы на RT.VVK.NOV в сторону аплинков. Вот что мы увидим:
My traceroute [v0.69]
BGP-Client (0.0.0.0)(tos=0x0 psize=64 bitpattern=0x00) Sun Apr 11 18:37:04 2021
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 50.0.0.0 0.0% 6 1.2 5.1 1.2 23.3 8.9
2. 10.2.2.6 0.0% 6 2.0 2.2 1.8 2.8 0.4
3. 10.2.2.2 0.0% 6 2.9 2.7 2.3 3.1 0.3
4. 10.0.0.14 0.0% 6 3.1 3.3 2.7 4.1 0.4
5. ???
10.0.0.14 - это интерфейс на RT.SPB.K12. Трафик ходит так, как нам нужно.
Default Route Adverisment with Policy Option Conditions
Policy Option Conditions позволяет анонсировать маршрут по умолчанию клиентам через различных аплинков в зависимости от того доступны ли они от них определённые префиксы.
Предположим, что у нас на RT.VVK.NOV появился клиент, которому нужно анонсировать маршрут по-умолчанию:
Настром между роутерами BGP-Сессию:
root@RT.VVK.NOV# show | compare
[edit interfaces]
+ ge-0/0/9 {
+ unit 0 {
+ family inet {
+ address 50.0.0.0/31;
+ }
+ }
+ }
[edit protocols bgp]
group intra-Sub-AS { ... }
+ group ip-transit {
+ type external;
+ neighbor 50.0.0.1 {
+ peer-as 500;
+ }
+ }
Заранее выключим AS8001, который анонсирует префикс. Посмотрим что мы будем видеть на клиентском роутере:
root@BGP-Client# run show route
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
40.0.0.0/24 *[Static/5] 02:43:22
Discard
40.0.0.1/32 *[Direct/0] 02:41:20
> via lo0.0
50.0.0.0/31 *[Direct/0] 02:43:22
> via ge-0/0/0.0
50.0.0.1/32 *[Local/0] 02:43:22
Local via ge-0/0/0.0
[edit]
root@BGP-Client# run show route receive-protocol bgp 50.0.0.0
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
Мы не принимаем по BGP ни одного префикса. Попробуем включить AS8001 и снова посмотреть на вывод команд:
root@BGP-Client# run show route
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 00:01:42, MED 17, localpref 100
AS path: 9000 I, validation-state: unverified
> to 50.0.0.0 via ge-0/0/0.0
40.0.0.0/24 *[Static/5] 02:47:53
Discard
40.0.0.1/32 *[Direct/0] 02:45:51
> via lo0.0
50.0.0.0/31 *[Direct/0] 02:47:53
> via ge-0/0/0.0
50.0.0.1/32 *[Local/0] 02:47:53
Local via ge-0/0/0.0
[edit]
root@BGP-Client# run show route receive-protocol bgp 50.0.0.0
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 0.0.0.0/0 50.0.0.0 17 9000 I
Такая конфигурация полезна, когда у клиента есть резерв, но он принимает только default-route. Если этот префикс не доступен, то мы перестаём анонсировать клиенту маршрут по умолчанию и он уходит на резерв.
Filter Based Forwarding (PBR for Cisco)
Предположим, что клиент, которого мы подключили ранее, испытывает трудности с доступом к нужной ему подсети с адресом 101.0.0.0/24 через прямой линк с AS9001. Трассировка выглядит сейчас так:
My traceroute [v0.69]
BGP-Client (0.0.0.0)(tos=0x0 psize=64 bitpattern=0x00) Sat Mar 13 14:10:07 2021
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 50.0.0.0 0.0% 34 1.4 1.6 1.0 2.3 0.3
2. 9.1.1.2 0.0% 34 1.8 2.0 1.6 2.8 0.3
3. 101.0.0.1 0.0% 33 5.0 8.3 4.3 81.2 14.5
По AS-PATH маршрута видно, что путь пакетов пролегает через RT.VVK.NOV->AS9001->AS8001. Соответственно нам нужно выбрать такой маршрут, чтобы он проходил через AS9000->AS9002->AS9001->AS80001.
root@RT.VVK.NOV# show | compare
[edit interfaces ge-0/0/9 unit 0 family inet]
+ filter {
+ input to-101.0.0.0;
+ }
[edit routing-options]
+ interface-routes { ## Импорт Direct маршрутов в таблицу 101.0.0.0-reroute.inet.0
+ rib-group inet ip-transit-group; ## Можно также импортировать маршруты из
+ } ## других протоколов, например OSPF. Делается это в соответствующей иерархии
+ rib-groups {
+ ip-transit-group { ##Указываем Source RIB и RIBs, куда импортировать маршруты
+ import-rib [ inet.0 101.0.0.0-reroute.inet.0 ];
+ }
+ }
[edit]
+ firewall { ##Если Dst IP для пакета 101.0.0.0/24, то маршрутизируем
+ filter to-101.0.0.0 { ## его согласно routing-instance 101.0.0.0-reroute
+ term 1 {
+ from {
+ source-address {
+ 40.0.0.0/24;
+ }
+ destination-address {
+ 101.0.0.0/24;
+ }
+ }
+ then {
+ routing-instance 101.0.0.0-reroute;
+ }
+ }
+ term default {
+ then accept;
+ }
+ }
+ }
+ routing-instances { ## А тут просто указываем next-hop для пакетов, попавших в
+ 101.0.0.0-reroute { ## эту routing-instance
+ instance-type forwarding;
+ routing-options {
+ static {
+ route 0.0.0.0/0 next-hop 9.2.2.0;
+ }
+ }
+ }
+ }
Что тут было сделано описано в комментариях к конфигу. Теперь трассировка выглядит так:
root@BGP-Client# run traceroute monitor 101.0.0.1 source 40.0.0.1
My traceroute [v0.69]
BGP-Client (0.0.0.0)(tos=0x0 psize=64 bitpattern=0x00) Sat Mar 13 16:20:09 2021
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 50.0.0.0 0.0% 11 1.4 1.6 1.1 2.4 0.4
2. 9.2.2.0 0.0% 10 2.1 2.2 1.9 2.7 0.3
3. 9.2.2.1 0.0% 10 94.7 11.3 1.8 94.7 29.3
4. 9.1.1.2 0.0% 10 2.3 2.4 2.2 3.0 0.2
5. 101.0.0.1 0.0% 10 5.6 5.6 4.4 6.2 0.7
