IBGP между EX4200 через VLAN

В общем, надо было IBGP поднять между 2 шасси из EX4200. Линк - агрегейт, на котором куча транков висит.
Почитал маны, везде пишут, что надо пиринговый адрес вешать на loopback интерфейс. Однако упоминается, что можно юзать и обычный иннтерфейс, но надо указать router-id.

Сделал так:

Router A:

Влан для пиринга:

set vlans internal-bgp description internal_bgp vlan-id 110
set vlans internal-bgp l3-interface vlan.110

RVI:

set interfaces vlan unit 110 family inet address 10.0.110.1/24
set interfaces vlan unit 110 description Internal_BGP_RVI

Прицепить тег на порт между VC:

set interfaces ae61 unit 0 family ethernet-switching vlan members internal-bgp

Определяем id роутера, дабы не полагаться на дефолт:

set routing-options router-id 10.0.110.1

Разрешаем адрес пира для коннекта по бгп:

set policy-options prefix-list pl-bgp-peers 10.0.110.2/32

Сессия, пока всё режектим (политику po-deny-all не привожу, и так ясно):

edit protocols bgp group ibgp_peers
set type internal
set local-address 10.0.110.1
set neighbor 10.0.110.2
export po-deny-all
import po-deny-all

Закоммитили.

Router B:

Всё тоже самое, только адреса свопаются.
Влан для пиринга:

set vlans internal-bgp description internal_bgp vlan-id 110
set vlans internal-bgp l3-interface vlan.110

RVI:

set interfaces vlan unit 110 family inet address 10.0.110.2/24
set interfaces vlan unit 110 description Internal_BGP_RVI

Прицепить тег на порт между VC:

set interfaces ae61 unit 0 family ethernet-switching vlan members internal-bgp

Определяем id роутера, дабы не полагаться на дефолт:

set routing-options router-id 10.0.110.2

Разрешаем адрес пира для коннекта по бгп:

set policy-options prefix-list pl-bgp-peers 10.0.110.1/32

Сессия, пока всё режектим (политику po-deny-all не привожу, и так ясно):

edit protocols bgp group ibgp_peers
set type internal
set local-address 10.0.110.2
set neighbor 10.0.110.1
export po-deny-all
import po-deny-all

Закоммитили.

Проверили сессию, увидели, что поднялась.
Ну а дальше - на одном конце делаем политику на экспорт нужных сетей, на втором - политику их импорта и наоборот.
Примерно так (эспорт с b, приём на a):

router-a# set protocols bgp group ibgp_peers import po-internal-bgp-receive
router-b# set protocols bgp group ibgp_peers export po-internal-bgp-announce

Экcпорт роутера B:

> show configuration policy-options policy-statement po-internal-bgp-announce
term a {
    from {
        prefix-list-filter pl-internal-bgp exact;
    }
    then accept;
}
term b {
    then reject;
}

В pl-internal-bgp перечислены префиксы сетей.

Импорт роутера A:

> show configuration policy-options policy-statement po-internal-bgp-receive
term a {
    from {
        prefix-list-filter pl-internal-bgp-receive exact;
    }
    then {
        preference 100;
        accept;
    }
}
term b {
    then reject;
}

pl-internal-bgp-receive - список принимаемых префиксов.
Приоритет меняем, чтобы в эти сети ходить напрямую, а не через дефолт, получаемый по бгп от провайдера (приоритет 170).

Смотрим, что сети получены )

generated route

Зачем они нужны и как ими пользоваться?
Я, когда в одной книжке наткнулся на них, не совсем понял их. Там упоминалось, что их можно использовать, когда надо дефолт отдавать с условием, чтобы он подох при падении сессии с вышестоящим пиром.
И вот тут я столкнулся дженерейтами непосредственно.

Что было:
2 канала, основной и резервный, соотв. имеются два bgp пира. Обоим анонсируем свои префиксы, получаем от обоих дефолты. В резервный канал префиксы препендим, дефолту через основной канал приоритет поднимаем. В случае, если основной ложится - всё само начинает работать через резерв, т.к. сессия умирает со всеми вытекающми. Естественно, может быть ситуация с мёртвым каналом и живой сессией, на этот случай отдельный механизм.
И ещё с пиром на резервном канале была ipv6 сессия, отдавали наш префикс и получали дефолт.

Необходимость:
Поднять ipv6 сессию с пиром на основном канале, с сохранением имеющейся схемы с автоматическим переходом на бекап.

Что получилось:
Оказалось, что наш пир на основном канале не получает ipv6 дефолт и поэтому отдаёт нам fullview, который к нам не пролезает. Собственно, даже при поддержке fullview пришлось бы что-то делать, чтобы передавать дальше.
В общем, из того, что к нам шло, я выбрал один раут - до одного из корневых ДНСов.
Дальше пришлось состряпать две политики.
Одна для импорта нужного раута по bgp:

term root_dns_a {
    from {
        route-filter 2001:503:ba3e::/48 exact;
    }
    then accept;
}
term deny_others {
    then reject;
}

Вторая - для инжекта раута в генерируемый маршрут (po-inject):

term inject_root_dns_only {
    from {
        neighbor 2a00:xxxx:0:13::1;
        route-filter 2001:503:ba3e::/48 exact;
    }
    then accept;
}
term deny_other {
    then reject;
}

И, наконец, поднимаем раут:

> show configuration routing-options rib inet6.0   

generate {
    route ::/0 policy po-inject;
}

В результате имеем 2 дефолта с разными приоритетами (за счёт дефолтных приоритетов аггрегейтов и бгп), в случае смерти сессии с пиром на основном канале - сгенерированный маршрут умрёт, ибо не будет ни одного contributed раута.

Linux для домашнего роутера

Обнаружил интересную штуку: OpenWRT
Это открытая прошивка для роутеров, основанная ни линуксе. мой девайc Acorp WR-G+, к сожалению, в список поддерживаемых устройств не входит.
эх, надо было Линксис брать..