Comments 6
Дело в том, что маршруты на ASBR лежат в таблице inet.3, а label-unicast сессия с удаленными PE строится из inet.0, и естественно на PE-ки ничего не отдается. Для этого надо сделать еще одну rib-группу на ASBR и перенести маршруты из inet.3 в inet.0
Почему бы просто не поднять с удалённым PE сессию из таблиц inet.3? Конфигурация станет однотипной, не будет дополнительной rib-group. Плюс не обязательно делать даже первую для экспорта своего loopback, так как в этом кейсе в удалённой AS он и не нужен. Если только для науки.
И, кстати, на ASBR вовсе не обязательно делать NHS политику, так как, похоже, что для eBGP-LU в Junos происходит замена next-hop и выделение новой метки по умолчанию.
root@ASBR-AS65535> show configuration protocols bgp
group as65534 {
family inet {
labeled-unicast {
rib {
inet.3;
}
}
}
export ps-bgp-lu-export;
peer-as 65534;
neighbor 100.0.0.1;
}
group internal {
type internal;
local-address 10.128.0.1;
family inet {
labeled-unicast {
rib {
inet.3;
}
}
}
neighbor 10.128.0.2;
}
root@ASBR-AS65535> show route receive-protocol bgp 100.0.0.1 extensive
inet.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 10.254.0.2/32 (1 entry, 1 announced)
Accepted
Route Label: 299808
Nexthop: 100.0.0.1
MED: 1
AS path: 65534 I
mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
root@ASBR-AS65535> show route advertising-protocol bgp 10.128.0.2 extensive
inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 10.254.0.2/32 (1 entry, 1 announced)
BGP group internal type Internal
Route Label: 299824
Nexthop: Self
Flags: Nexthop Change
MED: 1
Localpref: 100
AS path: [65535] 65534 I
root@ASBR-AS65535> show policy ps-bgp-lu-export
Policy ps-bgp-lu-export:
Term allowed:
from proto LDP
route filter:
10.128.0.0/24 prefix-length-range /32-/32
then accept
Term unnamed:
then reject
root@ASBR-AS65535>
в данном случае РЕ-ки пирятся по BGP и если сделать как вы предлагаете — пиринг не поднимется, так как маршрута не будет в inet.0, в итоге между автономками не будут передаваться VPNv4 маршурты — не будет связности. Тоже самое если бы был рефлектор — между рефлеторами нужна связность через inet.0. Придется делать риб группы на PE-ках, чего не очень хочется.
В данном кейсе отдавать лубпек ASBR нет особой необходимости, в реальности же у вас ASBR и PE будут в одном флаконе и отдавать лупбек в соседнюю автономку будет нужно.
NHS была нужна, так как маршурта до стыковочной сетки между ASBR нет внутри автономок — маршруты были бы неактивны без этой политики. Можно было бы интерфейс в сторону соседнего ASBR засунуть в igp и сделать его пассивным — кому что нравится.
В данном кейсе отдавать лубпек ASBR нет особой необходимости, в реальности же у вас ASBR и PE будут в одном флаконе и отдавать лупбек в соседнюю автономку будет нужно.
NHS была нужна, так как маршурта до стыковочной сетки между ASBR нет внутри автономок — маршруты были бы неактивны без этой политики. Можно было бы интерфейс в сторону соседнего ASBR засунуть в igp и сделать его пассивным — кому что нравится.
в данном случае РЕ-ки пирятся по BGP и если сделать как вы предлагаете — пиринг не поднимется, так как маршрута не будет в inet.0
Маршрут будет, так как resolve-vpn на PE, который у Вас в конфигурации, предполагает префиксы как в inet.0, так и в inet.3.
В данном кейсе отдавать лубпек ASBR нет особой необходимости, в реальности же у вас ASBR и PE будут в одном флаконе и отдавать лупбек в соседнюю автономку будет нужно.
В реальности что угодно может быть. Но как пример того, что можно столкнуться с такой проблемой, рассмотреть стоило, согласен.
NHS была нужна, так как маршурта до стыковочной сетки между ASBR нет внутри автономок — маршруты были бы неактивны без этой политики. Можно было бы интерфейс в сторону соседнего ASBR засунуть в igp и сделать его пассивным — кому что нравится.
Они были бы неактивны, если бы ASBR сохранял оригинальный next-hop eBGP-пира в UPDATE в сторону PE, я писал о том, что этого не происходит, он автоматически меняет его на свой даже без политики. В выводе видно, что в секции BGP у меня нет политики NHS, но при этом метка и next-hop меняются.
Они были бы неактивны, если бы ASBR сохранял оригинальный next-hop eBGP-пира в UPDATE в сторону PE, я писал о том, что этого не происходит, он автоматически меняет его на свой даже без политики. В выводе видно, что в секции BGP у меня нет политики NHS, но при этом метка и next-hop меняются.
Да, на сколько я помню, для LU сессии это так и работает, но по привычке на iBGP вешаю NHS. Ничего в этом страшного нет.
По поводу PE — можно делать сессию и с inet.0 и c inet.3. Как вам удобнее. Лично я использовал описанное в статье решение, вы можете использовать другое. У каждого свои грабли)
Sign up to leave a comment.
Подводные камни Inter-AS Option C на JunOS