FRRouting 6.0

Вышла версия стека протоколов FRRouting 6.0, которые является форком quagga.

... который является форком zebra.

Форки такие форки.

А с кваггой что?

Вышла версия стека протоколов FRRouting 6.0, которые является форком quagga.

Очень полезное знание, особенно если не знаешь, что такое frrouting и quagga.

Софтварная реализация свича/роутера с поддержкой динамической маршрутизации - ospf, bgp и прочие подобные вещи.

Софтварная реализация свича

нет

Не успели quagga форкнуть, как уже форк самого frrouting подъехал. Успехов им, главное чтоб разработка не закисла(как с quagga) :-(

алиасы? или хотябы намертво alias c exec conf t?

Очередной ненужный форк? Или там есть некие политические причины?

Очень полезное знание, особенно если не знаешь, что такое >>frrouting и quagga.

Ну вообще-то ваше присутствие на данном форуме уже заведомо предполагает подобное знание с вашей стороны, хотя-бы на уровне слухов.

Дело в том, что в одном из элементов форка frr лицензия apache 2.0

Но, BFD строго говоря, сам не является протоколом динамической маршрутизации, он что-то вроде APS в мире динамической маршрутизации.

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

Нет

Что именно «нет»?

BFD строго говоря, сам не является протоколом динамической маршрутизации

и нестрого тоже

Есть версия, которая упровляет openflow.

упровляет

корованы грабит?

OpenFlow ВНЕЗАПНО не совсем коммутация ибо он управляет потоками данных, а не пакетов. То есть - несколько более высокий уровень абстракции чем в случае коммутатора. То что на основе этих таблиц потоков строятся непосредственно таблицы коммутации - немного другой вопрос.

И самое главное отличие FRRouting от полумертвых предшественников - это поддержка EIGRP, пусть и в альфа-стадии. Это внушает надежду :)

поддержка EIGRP

не нужно

Вынужден согласиться с анонимом выше, что EIGRP за пределом DMVPN Phase 3 и ещё пары кейсов, действительно не так уж и востребован.

В конечном счёте RFC 7868 является лишь информационным и не содержит описания части возможностей, например EIGRP stub Routing. А значит реализация EIGRP за пределами экосистемы Cisco, всегда будет не полной или же, будет иметь какие-либо отличия в реализации той или иной возможности.

DMVPN Phase 3

afair, bgp более чем годится.

BFD (Bidrectional Forwarding Detection)

Думал, что в оригинале баг. Но нет, все правильно. Откуда надмозг взял про маршрутизацию?

Да и OSPF с ODR, тоже годятся, но Cisco рекомендует использовать EIGRP, и в данном случае, он более чем оправдан. В иных же случаях, не каких преимуществ перед OSPF, у него не наблюдается особых.

Судя по всему совершил ошибку при написании новости, излишне вольно распорядился при переводе имеющейся информацией.

В иных же случаях, не каких преимуществ перед OSPF, у него не наблюдается особых.

Кроме того что для пресловутых 95% небольших сетей (2-3-4 десятка маршрутизаторов), RIP (во всех вариантах) явно недостаточен, а OSPF - явно избыточен, но зато - гораздо сложней в настройке.

не содержит описания части возможностей, например EIGRP stub Routing.

Расскажи пожалуйста, а как это описать в стандарте, в которым описан ПРОТОКОЛ?

О какой сложности настройки идёт речь для OSFP в конфигурации одной области?

Не понял сути вопроса, ровно так же, как описаны другие особенности работы протокола. В конечном счёте в Hello пакетах в случае Stub появляется дополнительное TLV Stub Flags к примеру, значит необходимо описать формат полей и тд.

Вы не перепутали EIGRP и OSPF? То о чем вы пишите - это OSPF. :)

Нет, не перепутал и вот почему. Согласно RFC 2328 - OSPF Version 2, смежные OSPF маршрутизаторы не объявляют тип области в своих Hello пакетах:

Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: Hello Packet (1)
        Packet Length: 48
        Source OSPF Router: 6.6.6.6
        Area ID: 0.0.0.4
        Checksum: 0x7f68 [correct]
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    OSPF Hello Packet
        Network Mask: 255.255.255.252
        Hello Interval [sec]: 10
        Options: 0x10, (L) LLS Data block
        Router Priority: 1
        Router Dead Interval [sec]: 40
        Designated Router: 172.16.4.1
        Backup Designated Router: 172.16.4.2
        Active Neighbor: 1.1.1.1
    OSPF LLS Data Block
        Checksum: 0xfff6
        LLS Data Length: 12 bytes
        Extended options TLV
            TLV Type: 1
            TLV Length: 4
            Options: 0x00000001, (LR) LSDB Resynchronization

Да, это типичный OSPF Hello пакет который направляет OSPF маршрутизатор и в данном случае, 4 область является Stub областью.

К сожалению RFC 7868 - Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP) не содержит описание для Hello пакетов, содержащих Stub Flags TLV, но, дамп нам всё покажет:

Frame 88: 114 bytes on wire (912 bits), 114 bytes captured (912 bits) on interface 0
Ethernet II, Src: aa:bb:cc:00:31:00 (aa:bb:cc:00:31:00), Dst: aa:bb:cc:00:21:10 (aa:bb:cc:00:21:10)
Internet Protocol Version 4, Src: 172.16.0.6, Dst: 172.16.0.2
Generic Routing Encapsulation (IP)
Internet Protocol Version 4, Src: 10.0.0.2, Dst: 224.0.0.10
Cisco EIGRP
    Version: 2
    Opcode: Hello (5)
    Checksum: 0xe6bb [correct]
    [Checksum Status: Good]
    Flags: 0x00000000
    Sequence: 0
    Acknowledge: 0
    Virtual Router ID: 0 (Address-Family)
    Autonomous System: 1
    Parameters
    Software Version: EIGRP=18.0, TLV=2.0
    Peer Stub Information
        Type: Peer Stub Information (0x0006)
        Length: 6
        Stub Options: 0x0009, Connected, Redistributed
    Peer Topology ID List

А вот это типичный EIGRP Hello пакет Stub маршрутизатора, обратите внимание на TLV Peer Stub Information (0x0006), вы не найдёте его в RFC 7868.

Поспешил, нужно было дополнить, что в заголовке OSPF Hello пакета есть Options поле, в котором маршрутизатор может указать свои возможности другому смежному маршрутизатору.

A.2 The Options field

The OSPF Options field is present in OSPF Hello packets, Database Description packets and all LSAs. The Options field enables OSPF routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPF routers. Through this mechanism routers of differing capabilities can be mixed within an OSPF routing domain. ... Routers should reset (i.e. clear) unrecognized bits in the Options field when sending Hello packets or Database Description packets and when originating LSAs. Conversely, routers encountering unrecognized Option bits in received Hello Packets, Database Description packets or LSAs should ignore the capability and process the packet/LSA normally.

Но главное тут, _может_, в примере выше, не IR не ABR не указывают друг-другу, что они "(E) External Routing: Not capable".