В продолжении предыдущей статьи Juniper и Policy-based routing ( PBR ) появилась задача когда необходимо чтобы маршруты из таблицы inet.2 (mBGP) попадали не только в нее, но и в таблицу inet.0 (eBGP).

Расскажу и покажу как это сделали мы.

Дано

• MX80 (JUNOS 10.4R1.9)
• апстрим с двумя BGP сессиями eBGP и mBGP

Задача

Импортировать маршруты принимаемые в сессии mBGP (роутинг таблица inet.2) в таблицу сессии eBGP (таблица inet.0).

Реализация

Состояние ДО изменений:

Для примера возьмем маршрут до подсети 11.11.11.192/28.
Посмотрим текущий маршрут до этой подсети:

juniper-MX80> show route terse 11.11.11.192
inet.2: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

Видим что данный маршрут находится только в таблице inet.2, это то мы и будем «исправлять».

Приступим. Как и в случае с PBR нам поможет механизм rib-groups.
Создадим rib группы:

routing-options {
    rib-groups {
        bgp-multicast-rg {
            export-rib inet.2;
            import-rib [ inet.2 inet.0 ];
        }
        bgp-unicast-rg {
            export-rib inet.0;
            import-rib inet.0;
        }
    }
}

Мы создали две rib группы: одну для unicast, другую для multicast. В rib группе multicast в import-rib мы указали, что принимаемые маршруты нужно импортировать и в таблицу inet.0.

Теперь опишем эти rib группы в protocols bgp:

protocols {
    bgp {
        family inet {
            unicast {
                rib-group bgp-unicast-rg;
            }
            multicast {
                rib-group bgp-multicast-rg;
            }
        }
    }
}

Ну и сами BGP пиры, один eBGP, другой mBGP:

protocols {
    bgp {
        log-updown;
        local-as 65000;
        group ebgp {
            type external;
            no-advertise-peer-as;
            neighbor 10.10.10.229 {
                description eBGP_peer;
                import bgp-import;
                family inet {
                    unicast;
                }
                export bgp-export;
                peer-as 65500;
            }
        }
        group mbgp {
            type external;
            no-advertise-peer-as;
            neighbor 20.20.20.209 {
                description mBGP_peer;
                import bgp-mcast-import;
                family inet {
                    multicast;
                }
                export bgp-mcast-export;
                peer-as 65500;
            }
        }
    }
}

После commit`а смотрим появился ли маршрут в таблице inet.0:

juniper-MX80> show route terse 11.11.11.192

inet.0: 51 destinations, 51 routes (44 active, 0 holddown, 7 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

inet.2: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

А вот теперь мы видим что наш маршрут присутствует в двух таблицах, что нам и было надо.

Ссылки

• Interdomain multicast routing: practical Juniper Networks and Cisco systems
• rib-group

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Я уже писал об использовании PBR на оборудовании Cisco, а в этой статье мы будем это делать на Juniper.

PBR предоставляет механизм реализации пересылки (forwarding)/ маршрутизации (routing) пакетов данных, основанный на политике, представляющей собой набор правил, определенной администраторами сети. Это предоставляет более гибкий механизм для обработки пакетов на маршрутизаторах, дополняя существующий механизм, предоставленный протоколами маршрутизации.

Дано

• ISP#1 (10.0.0.1/30), подключение по BGP
• ISP#2, подключение по BGP
• Juniper MX240

Задача

Настроить BGP сессии с двумя ISP`ами, а так же обеспечить работу статически пророученную на нас ISP#1 небольшую реальную подсеть, для примера скажем это будет 128.1.1.0/24.

Реализация

Если не применить PBR политику к статически пророученной ISP#1 подсети, то при передаче пакетов будут использовать маршруты, которые были получены по BGP от двух ISP`ов и пакеты от реальной подсети ISP#1 могут уходить в канал через ISP#2, что в большинстве случаях работать не будет, в виду того что ISP#2 не выпустит чужие подсети через свою инфрастуктуру или вы получите не симметричную трассу. К сожалению мы по своей работе сталкиваемся с провами, которые не осуществляют фильтрацию чужих подсетей, что развязывает руки DDoS`ерам… когда при атаках они подделывают SRC адреса. Я искренне надеюсь, что ты (читатель) осуществляешь фильтрацию перед тем как «выплюнуть» пакет из своей сети в свой внешний канал.

Немного теории по названиям роут таблиц в Junos`е:

JUNOS default routing tables Name

• inet.0 — IPv4 unicast routes. BGP, IS-IS, OSPF, and RIP store their routing information in this table and use the routes in this table when advertising routes to their neighbors. Configured static routes are also stored in this table.
• inet.1 — Multicast forwarding cache. DVMRP and PIM store their routing information in this table.
• inet.2 — Used by MBGP to provide reverse path forwarding (RPF) checks.
• inet.3 — Traffic engineering paths. Stores path and label information.
• inet6.0 — IPv6 unicast routes.
• iso.0 — ISO routes for IS-IS.
• mpls.0 — MPLS label-switched path (LSP) next hops.

В реализации задачи нам поможет механизм rib-groups:

rib-groups group-name {
     import-policy [ policy-names ];
     import-rib [ routing-table-names ];
     export-rib routing-table-name;
}

А так же interface-routes:

interface-routes {
     rib-group group-name;
}

Приступим к настойке и для начала создадим rib группу, в конфиге получим:

root@mx240# show routing-options
interface-routes {
    rib-group inet isp1-static-group;
}
rib-groups {
    isp1-static-group {
        import-rib [ inet.0 isp1-static.inet.0 ];
    }
}

Затем создадим routing-instance isp1-static в которой и укажем default на ISP#1:

root@mx240# show routing-instances
isp1-static {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 10.0.0.1;
        }
    }
}

Теперь нам надо как то match`ить пакеты где source адресом выступает статически пророученная подсеть реальников 128.1.1.0/24 и перенапралять их в routing-instance isp1-static.
В этом нам поможет firewall filter:

root@mx240# show firewall filter isp1-static-subnets
term match {
    from {
        source-address {
            128.1.1.0/24;
        }
    }
    then {
        routing-instance isp1-static;
    }
}
term default {
    then accept;
}

Этим мы добиваемся того, что пакеты из подсети 128.1.1.0/24 будут маршрутизироватся по таблице isp1-static, а все остальные подсети будут использовать таблицу по умолчанию inet.

Что нам осталось сделать ?
Осталось применить наш filter на Layer-3 интерфейсе роутера откуда у нас поступают пакеты от клиентов с source адресом этой подсети.
В моем примере это vlan 3, т.к. именно за данным интерфейсом находится ещё один роутер, для клиентов в подсети 128.1.1.0/24:

root@mx240# show routing-options static
route 128.1.1.0/24 {
    next-hop 172.16.1.2;
    retain;
}

Применим filter:

root@mx240# show interfaces irb
unit 3 {
    family inet {
        filter {
            input isp1-static-subnets;
        }
        address 172.16.1.3/29;
    }
}

Все приготовления сделаны, теперь можно commit`ить конфигурацию и проверять её работу.
Посмотрим маршруты в созданной нами routing-instance isp1-static:

root@mx240> show route table isp1-static.inet.0
isp1-static.inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 1d 18:51:33
                    > to 10.0.0.1 via irb.800
....skiped....

Как мы можем видеть наш default в данной таблице присутствует и таким образом все пакеты с SRC-адресом из подсети 128.1.1.0/24 будут отправлены через интерфейс на ISP#1 10.0.0.1.

Ссылки

• Creating Routing Table Groups
• Configuring How Interface Routes Are Imported into Routing Tables
• Demystifying Juniper’s rib-groups
• Juniper PBR (сохраненная копия)

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

В продолжении статьи «Конфигурация OSPF на оборудовании Cisco Systems» посмотрим как в данной схеме можно выполнить редистрибуцию статических маршрутов, ну скажем на маршрутизаторе Б, в протокол OSPF.

Например на маршрутизаторе Б появился статический маршрут, ну скажем 192.168.0.0/24:

Switch> enable
Switch# configure terminal
Switch(config)# ip route 192.168.0.0 255.255.255.0 10.0.1.10

и мы хотим «вбросить» этот маршрут в OSPF.

С этой задачей нам поможет справится редистрибуция маршрутов из одного протокола в другой.

Приступим

1. Создадим access-list, по нему мы будем match`ить нужный нам маршрут(ы):

Switch(config)# ip access-list standard 10
Switch(config-std-nacl)# permit 192.168.0.0 0.255.255.255
Switch(config-std-nacl)# exit

2. Создадим маршрутную карту, в которой укажем access-list созданный в п.1:

Switch(config)# route-map redistr-static permit 100
Switch(config-route-map)# match ip address 10
Switch(config-route-map)# exit

3. Укажем OSPF, что мы хотим сделать редистрибуцию:

Switch(config)# router ospf 10
Switch(config-router)# redistribute static route-map redistr-static

4. Сохраним конфиг:

Switch(config-router)# exit
Switch(config)# exit
Switch# wri

Вот и все. Теперь все статические маршруты, попадающие под access-list 10 будут редистрибутированы в OSPF.

Не могу не подметить, что в команде redistribute, можно:
а) задать и метрику, с которой будет выполняться данная редистрибуция:

Switch(config-router)# redistribute static route-map redistr-static metric 15

б) задать tag, с которым будет распространяться маршрут (по нему, на других маршрутизаторах, можно определять откуда маршрут пришел):
Switch(config-router)# redistribute static route-map redistr-static metric 15 tag 1

Посмотрим, route-map и access-list на маршрутизаторе Б:
Switch# show route-map redistr-static

route-map redistr-static, permit, sequence 100
Match clauses:
ip address (access-lists): 10
Set clauses:
Policy routing matches: 0 packets, 0 bytes

Switch# show access-lists 10

Standard IP access list 10
    10 permit 192.168.0.0, wildcard bits 0.255.255.255 (2 matches)

На маршрутизаторе А вы должны видеть этот маршрут:
Switch# show ip route ospf | inc 192.168.0.0/24

O E2    192.168.0.0/24 [110/15] via 10.0.255.2, 1m, Vlan10

На маршрутизаторе В также:
Switch# show ip route ospf | inc 192.168.0.0/24

O E2    192.168.0.0/24 [110/15] via 10.0.255.9, 1m, Vlan100

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

З.Ы.Ы. Очепятки возможны. Если вы заметили неточность или у вас есть вопросы по данной схеме, то вы можете написать об этом на нашем форуме с соответствующем разделе.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

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

Посмотрим на следующую схему сети. Что имеется:

• 3шт. catalyst 3560G с включенной функцией маршрутизации
• маршрутизатор А связывает нашу сеть с сетью Интернет
• к маршрутизаторам Б и В подключены клиенты, находящиеся в 200-ом влане и IP-подсетях 10.0.1.0/24 и 10.0.2.0/24
• у маршрутизаторов Б и В указан статический маршрут до default gateway (маршрутизатор А, 10.0.255.1)

Схема сети до включения OSPF

В данной схеме OSPF вроде бы совсем не к чему. Можно его конечно запустить, но плюсов он особо не принесет. А теперь сделаем следущее: соединим маршрутизаторы Б и В между собой. В такой схеме, можно как минимум обеспечить резервирование линков от маршрутизатора Б до А и от В до А, а также быстро заводить новые подсети и распространить маршруты до них в нашей сети — динамическая маршрутизация (в данном случае OSPF) нам в этом поможет.

Итак полученная схема, на которой, как мне кажется, вы сможете понять/посмотреть принципы работы OSPF, которую мы и будем настраивать:

Схема с OSPF

Мы рассмотрим работу OSPF в broadcast среде и на point-to-point соединении.

Приступим

Маршрутизатор А

Switch> enable
Switch# configure terminal
Switch(config)# vlan 10
Switch(config-vlan)# name main
Switch(config-vlan)# exit
Switch(config)# int vlan 10
Switch(config-if)# ip address 10.0.255.1 255.255.255.248

Явно укажем тип среды, в котором будет работать этот интерфейс в OSPF:

Switch(config-if)# ip ospf network broadcast
Switch(config-if)# exit

Продолжаем:

Switch(config)# ip routing
Switch(config)# ip subnet-zero
Switch(config)# ip classless

Переходим к настройке OSPF, номер процесса у нас будет 10:

Switch(config)# router ospf 10
Switch(config-router)# log-adjacency-changes

Зададим RID 255.255.255.255, для того чтобы данный маршрутизатор при выборах DR и BDR всегда выбирался как DR (у кого больший router-id тот и победит в выборах за место DR в сети если у всех маршрутизаторов одинаковый приоритет), а так же потом будет легко его определять ( в выводах show команд) по этому номеру RID как «верхний» маршрутизатор:

Switch(config-router)# router-id 255.255.255.255

Включим протокол OSPF на интерфейсе vlan 10 в Area 0:

Switch(config-router)# network 10.0.255.0 0.0.0.7 area 0

Команда network означает, что маршрутизатор включит протокол OSPF на тех IP интерфейсах, которые попадают под указанную маску подсети.

Укажем что мы хотим распространять default маршрут в сеть OSPF, т.е. данный маршрутизатор будет распространять маршрут по умолчанию:

Switch(config-router)# default-information originate

Сохраним конфигурацию:

Switch(config-router)# exit
Switch(config)# exit
Switch# wri

Маршрутизатор Б

Создадим влан 10, в котором «живут» маршрутизаторы А и В:
Switch> enable
Switch# configure terminal
Switch(config)# vlan 10
Switch(config-vlan)# name main

Создадим влан 200, в котором «живут» клиенты:

Switch(config-vlan)# vlan 200
Switch(config-vlan)# name clients
Switch(config-vlan)# exit

Зададим IP-адреса созданным вланам

Switch(config)# int vlan 10
Switch(config-if)# ip address 10.0.255.2 255.255.255.248
Switch(config-if)# ip ospf network broadcast
Switch(config-if)# int vlan 200
Switch(config-if)# ip address 10.0.1.1 255.255.255.0
Switch(config-if)# exit

Создадим влан 100, в по которому будут обмениваться маршрутизаторы Б и В

Switch(config)# vlan 100
Switch(config-vlan)# name backup
Switch(config-vlan)# exit
Switch(config)# int vlan 100
Switch(config-if)# ip address 10.0.255.9 255.255.255.252

Явно укажем тип среды, в котором будет работать этот интерфейс в OSPF, но не такой как на маршрутизаторе А, т.к. между маршрутизаторами Б и В явно выраженное p2p соединение и нет смысла проводить выборы DR и BDR на p2p линке, там всегда будет только два маршрутизатора: Б и В.

Избавим протокол OSPF от этой необходимости:

Switch(config-if)# ip ospf network point-to-point
Switch(config-if)# exit

Продолжаем:

Switch(config)# ip routing
Switch(config)# ip subnet-zero
Switch(config)# ip classless

Переходим к настройке OSPF. Номер процесса (10) может отличаться, т.к. OSPF не вставляет номер процесса в отправляемые пакеты, но мы оставим 10, мне так удобнее ;):

Switch(config)# router ospf 10
Switch(config-router)# log-adjacency-changes
Switch(config-router)# router-id 1.1.1.1
Switch(config-router)# network 10.0.255.0 0.0.0.7 area 0

Опишем интерфейс vlan 100, но тут я сделаю немного по другому, для примера:

Switch(config-router)# network 10.0.255.9 0.0.0.0 area 0
Обратите внимание на маску, которая равна 0.0.0.0. Таким образом мы указали OSPF, что только интерфейс с данным адресом участвует в OSPF.

Сделаем запись о сети 10.0.1.0/24:

Switch(config-router)# network 10.0.1.0 0.0.0.255 area 0

Сохраним конфигурацию:

Switch(config-router)# exit
Switch(config)# exit
Switch# wri

Маршрутизатор В

Создадим влан 10, в котором «живут» маршрутизаторы А и Б и влан под клиентов:
Switch> enable
Switch# configure terminal
Switch(config)# vlan 10
Switch(config-vlan)# name main
Switch(config-vlan)# vlan 200
Switch(config-vlan)# name clients
Switch(config-vlan)# exit

Зададим IP-адреса на вланы:

Switch(config)# int vlan 10
Switch(config-if)# ip address 10.0.255.3 255.255.255.248
Switch(config-if)# ip ospf network broadcast
Switch(config-if)# int vlan 200
Switch(config-if)# ip address 10.0.2.1 255.255.255.0
Switch(config-if)# exit

Создадим влан 100, в по которому будут обмениваться маршрутизаторы В и Б

Switch(config)# vlan 100
Switch(config-vlan)# name backup
Switch(config-vlan)# exit
Switch(config)# int vlan 100
Switch(config-if)# ip address 10.0.255.10 255.255.255.252
Switch(config-if)# ip ospf network point-to-point
Switch(config-if)# exit

Продолжаем:

Switch(config)# ip routing
Switch(config)# ip subnet-zero
Switch(config)# ip classless
Switch(config)# router ospf 10
Switch(config-router)# log-adjacency-changes
Switch(config-router)# router-id 2.2.2.2
Switch(config-router)# network 10.0.255.0 0.0.0.7 area 0
Switch(config-router)# network 10.0.255.10 0.0.0.0 area 0
Switch(config-router)# network 10.0.2.0 0.0.0.255 area 0
Switch(config-router)# exit
Switch(config)# exit
Switch# wri

Вот в принципе и все, что было необходимо сделать, чтобы протокол OSPF заработал в этой схеме.
Если вы ввсе сделали правильно, то по команде:

Switch# sh ip ospf neighbor

На маршрутизаторе А, вы увидите:

Neighbor ID     Pri   State       Dead Time   Address        Interface
2.2.2.2       0   FULL/BDR        00:00:30    10.0.255.3     Vlan10
1.1.1.1       0   FULL/DROTHER    00:00:39    10.0.255.2     Vlan10

На маршрутизаторе Б:

Neighbor ID     Pri   State         Dead Time   Address         Interface
255.255.255.255   0   FULL/DR       00:00:32    10.0.255.1      Vlan10
2.2.2.2           0   FULL/-        00:00:33    10.0.255.10     Vlan100

На маршрутизаторе В:

Neighbor ID     Pri   State         Dead Time   Address         Interface
255.255.255.255   0   FULL/DR       00:00:32    10.0.255.1      Vlan10
1.1.1.1           0   FULL/-        00:00:33    10.0.255.9      Vlan100

Посмотрите приходящие маршруты по протоколу OSPF:

Switch# show ip route ospf

На маршрутизаторах Б и В среди маршрутов приходящих по OSPF вы должны видеть и default:

O*E2 0.0.0.0/0 [110/1] via 10.0.255.1, 00:01:02, Vlan10

На маршрутизаторе Б, маршрут до сети 10.0.2.0/24 будет проходить по vlan 100, т.к. это кратчайший маршрут:

O       10.0.2.0/24 [110/2] via 10.0.255.10, 00:00:53, Vlan100

Соответственно на маршрутизаторе В:

O       10.0.1.0/24 [110/2] via 10.0.255.9, 00:00:53, Vlan100

Вот ещё несколько полезных команд.
show ip ospf interface
show ip ospf
show ip ospf database

Если по show ip ospf neighbor ничего нет, то:

• проверьте правильно ли вы все сконфигурировали
• «ходит» ли multicast по этим каналам
• не выставлен ли storm-control или ACL на multicast
• воспользуйтесь следующими командами debug:
  • debug ip ospf
    
  • debug ip ospf adj
  • debug ip ospf hello
  • debug ip ospf events
  • debug ip ospf packet

Заключение

Протокол OSPF не так прост как может показаться. Я рассмотрел только начало и совсем немного из того, что умеет данный протокол. В данной схеме, благодаря протоколу OSFP, при падении линков между маршрутизаторами Б и А или В и А связность сети не потеряется и пользователи из IP сетей 10.0.1.0/24 и 10.0.2.0/24 всегда будут иметь возможность обмениваться трафиком между собой, а также с сетью Интернет потому, что мы вбросили default маршрут в сеть OSPF.

Ссылки:

• Open Shortest Path First (OSPF)
• Configuring OSPF

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

З.Ы.Ы. Очепятки возможны. Если вы заметили неточность или у вас есть вопросы по данной схеме, то вы можете написать об этом на нашем форуме с соответствующем разделе.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

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

OSPF (Open Shortest Path First) — протокол динамической маршрутизации, основанный на технологии отслеживания состояния канала (link-state technology) и использующий для нахождения кратчайшего пути Алгоритм Дейкстры (Dijkstra’s algorithm).

Последняя версия протокола представлена в RFC 2328. Протокол OSPF представляет собой протокол внутреннего шлюза (Interior Gateway Protocol — IGP), распространяет информацию о доступных маршрутах между маршрутизаторами одной автономной системы.

OSPF предлагает решение следующих задач:

• Увеличение скорости сходимости;
• Поддержка сетевых масок переменной длины (VLSM);
• Достижимость сети;
• Использование пропускной способности;
• Метод выбора пути.

Теория

Терминология протокола OSPF

• Объявление о состоянии канала (link-state advertisement, LSA) — объявление описывает все каналы маршрутизатора, все интерфейсы и состояние каналов.
• Состояние канала (link state) — состояние канала между двумя маршрутизаторами; обновления происходят при помощи пакетов LSA.
• Метрика (metric) — условный показатель «стоимости» пересылки данных по каналу;
• Автономная система (autonomous system) — группа маршрутизаторов, обменивающаяся маршрутизирующей информацией с помощью одного протокола маршрутизации.
• Зона (area) — совокупность сетей и маршрутизаторов, имеющих один и тот же идентификатор зоны.
• Соседи (neighbours) — два маршрутизатора, имеющие интерфейсы в общей сети.
• Состояние соседства (adjacency) — взаимосвязь между определенными соседними маршрутизаторами установленная с целью обмена информацией маршрутизации.
• Hello-пакеты (hello packets) — используются для поддержания соседских отношений.
• База данных соседей (neighbours database) — список всех соседей.
• База данных состояния каналов (link state database, LSDB) — список всех записей о состоянии каналов. Встречается также термин топологическая база данных (topological database), употребляется как синоним базы данных состояния каналов.
• Идентификатор маршрутизатора (router ID, RID) — уникальное 32-битовое число, которое уникально идентифицирует маршрутизатор в пределах одной автономной системы.
• Выделенный маршрутизатор (designated router, DR) — управляет процессом рассылки LSA в сети. Каждый маршрутизатор сети устанавливает отношения соседства с DR. Информация об изменениях в сети отправляется DR, маршрутизатором обнаружившим это изменение, а DR отвечает за то, чтобы эта информация была отправлена остальным маршрутизаторам сети.Недостатком в схеме работы с DR маршрутизатором является то, что при выходе его из строя должен быть выбран новый DR. Новые отношения соседства должны быть сформированы и, пока базы данных маршрутизаторов не синхронизируются с базой данных нового DR, сеть будет недоступна для пересылки пакетов. Для устранения этого недостатка выбирается BDR.
• Резервный выделенный маршрутизатор (backup designated router, BDR). Каждый маршрутизатор сети устанавливает отношения соседства не только с DR, но и BDR. DR и BDR также устанавливают отношения соседства и между собой. При выходе из строя DR, BDR становится DR и выполняет все его функции. Так как маршрутизаторы сети установили отношения соседства с BDR, то время недоступности сети минимизируется.

Краткое описание работы протокола

1. Маршрутизаторы обмениваются hello-пакетами через все интерфейсы на которых активирован OSPF. Маршрутизаторы разделяющие общий канал передачи данных становятся соседями, когда они приходят к договоренности об определенных параметрах указанных в их hello-пакетах.
2. На следующем этапе работы протокола маршрутизаторы будут пытаться перейти в состояние соседства со своими соседями. Переход в состояние соседства определяется типом маршрутизаторов обменивающихся hello-пакетами и типом сети по которой передаются hello-пакеты. OSPF определяет несколько типов сетей и несколько типов маршрутизаторов. Пара маршрутизаторов, находящихся в состоянии соседства синхронизирует между собой базу данных состояния каналов.
3. Каждый маршрутизатор посылает объявление о состоянии канала маршрутизаторам с которыми он находится в состоянии соседства.
4. Каждый маршрутизатор получивший объявление от соседа записывает информацию передаваемую в нем в базу данных состояния каналов маршрутизатора и рассылает копию объявления всем другим своим соседям.
5. Рассылая объявления через зону, все маршрутизаторы строят идентичную базу данных состояния каналов маршрутизатора.
6. Когда база данных построена, каждый маршрутизатор использует алгоритм кратчайший путь первым для вычисления графа без петель, который будет описывать кратчайший путь к каждому известному пункту назначения с собой в качестве корня. Этот граф это дерево кратчайшего пути.
7. Каждый маршрутизатор строит таблицу маршрутизации из своего дерева кратчайшего пути.

В сетях со множественным доступом отношения соседства должны быть установлены между всеми маршрутизаторами. Это приводит к тому, что рассылается большое количество копий LSA. Если, к примеру, количество маршрутизаторов в сети со множественным доступом равно n, то будет установлено n(n-1)/2 отношений соседства. Каждый маршрутизатор будет рассылать n-1 LSA своим соседям, плюс одно LSA для сети, в результате сеть сгенерирует n² LSA.

Для предотвращения проблемы рассылки копий LSA в сетях со множественным доступом выбираются DR и BDR.

Маршрутизатор, выбранный DR или BDR в одной присоединенной к нему сети со множественным доступом, может не быть DR (BDR) в другой присоединенной сети. Роль DR (BDR) является свойством интерфейса, а не свойством всего маршрутизатора.

Таймеры протокола

• HelloInterval — Интервал времени в секундах по истечению которого маршрутизатор отправляет следующий hello-пакет с интерфейса. Для широковещательных сетей и сетей точка-точка значение по умолчанию, как правило, 10 секунд. Для нешироковещательных сетей со множественным доступом значение по умолчанию 30 секунд.
• RouterDeadInterval — Интервал времени в секундах по истечению которого сосед будет считаться «мертвым». Этот интервал должен быть кратным значению HelloInterval. Как правило, RouterDeadInterval равен 4 интервалам отправки hello-пакетов, то есть 40 секунд.
• Wait Timer — Интервал времени в секундах по истечению которого маршрутизатор выберет DR в сети. Его значение равно значению интервала RouterDeadInterval.
• RxmtInterval — Интервал времени в секундах по истечению которого маршрутизатор повторно отправит пакет на который не получил подтверждения о получении (например, Database Description пакет или Link State Request пакеты). Это интервал называется также Retransmit interval. Значение интервала 5 секунд.

Типы маршрутизаторов

Внутренний маршрутизатор (internal router) — маршрутизатор все интерфейсы которого принадлежат одной зоне. У таких маршрутизаторов только одна база данных состояния каналов.

Пограничный маршрутизатор (area border router, ABR) — соединяет одну или больше зон с магистральной зоной и выполняет функции шлюза для межзонального трафика. У пограничного маршрутизатора всегда хотя бы один интерфейс принадлежит магистральной зоне. Для каждой присоединенной зоны маршрутизатор поддерживает отдельную базу данных состояния каналов.

Магистральный маршрутизатор (backbone router) — маршрутизатор у которого всегда хотя бы один интерфейс принадлежит магистральной зоне. Определение похоже на пограничный маршрутизатор, однако магистральный маршрутизатор не всегда является пограничным. Внутренний маршрутизатор интерфейсы которого принадлежат нулевой зоне, также является магистральным.

Пограничный маршрутизатор автономной системы (AS boundary router, ASBR) — обменивается информацией с маршрутизаторами принадлежащими другим автономным системам. Пограничный маршрутизатор автономной системы может находиться в любом месте автономной системы и быть внутренним, пограничным или магистральным маршрутизатором.

Типы объявлений о состоянии канала (LSA)

Type 1 LSA — Router LSA — объявление о состоянии каналов маршрутизатора. Эти LSA распространяются всеми маршрутизаторами. В LSA содержится описание всех каналов маршрутизатора и стоимость (cost) каждого канала. Распространяются только в пределах одной зоны.

Type 2 LSA — Network LSA — объявление о состоянии каналов сети. Распространяется DR в сетях со множественным доступом. В LSA содержится описание всех маршрутизаторов присоединенных к сети, включая DR. Распространяются только в пределах одной зоны.

Type 3 LSA — Network Summary LSA — суммарное объявление о состоянии каналов сети. Объявление распространяется пограничными маршрутизаторами. Объявление описывает только маршруты к сетям вне зоны и не описывает маршруты внутри автономной системы. Пограничный маршрутизатор отправляет отдельное объявление для каждой известной ему сети.

Когда маршрутизатор получает Network Summary LSA от пограничного маршрутизатора он не запускает алгоритм вычисления кратчайшего пути. Маршрутизатор просто добавляет к стоимости маршрута указанного в LSA стоимость маршрута к пограничному маршрутизатору. Затем маршрут к сети через пограничный маршрутизатор помещается в таблицу маршрутизации.

Type 4 LSA — ASBR Summary LSA — суммарное объявление о состоянии каналов пограничного маршрутизатора автономной системы. Объявление распространяется пограничными маршрутизаторами. ASBR Summary LSA отличается от Network Summary LSA тем, что распространяется информация не о сети, а о пограничном маршрутизаторе автономной системы.

Type 5 LSA — AS External LSA — объявления о состоянии внешних каналов автономной системы. Объявление распространяется пограничным маршрутизатором автономной системы в пределах всей автономной системы. Объявление описывает маршруты внешние для автономной системы OSPF или маршруты по умолчанию (default route) внешние для автономной системы OSPF.

Type 7 LSA — AS External LSA for NSSA — объявления о состоянии внешних каналов автономной системы в NSSA зоне. Это объявление может передаваться только в NSSA зоне. На границе зоны пограничный маршрутизатор преобразует type 7 LSA в type 5 LSA.

Типы зон

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

Разделение на зоны позволяет:

• Снизить нагрузку на ЦПУ маршрутизаторов за счет уменьшения количества перерасчетов по алгоритму SPF
• Уменьшить размер таблиц маршрутизации
• Уменьшить количество пакетов обновлений состояния канала

Каждой зоне присваивается идентификатор зоны (area ID). Идентификатор может быть указан в десятичном формате или в формате записи IP-адреса. Однако идентификаторы зон не являются IP-адресами и могут совпадать с любым назначенным IP-адресом.

Магистральная зона (backbone area)

Магистральная зона (известная также как нулевая зона (Area 0) или зона 0.0.0.0) формирует ядро сети OSPF. Все остальные зоны ДОЛЖНЫ быть соединены с ней, и межзональная маршрутизация происходит через маршрутизатор соединенный с магистральной зоной. Магистральная зона ответственна за распространение маршрутизирующей информации между немагистральными зонами. Магистральная зона должна быть смежной с другими зонами, но она не обязательно должна быть физически смежной; соединение с магистральной зоной может быть установлено и с помощью виртуальных каналов (virtual links).