2_alex

Между парами CE-A(A7) и R1, CE-B(B8) и R3 поднят ospf, между R1 и R3 MP-BGP В лабе предлагается поднять shamlink между R1 и R3 в vrf vpn-a, чтобы CE-A и CE-B видел маршруты друг друга "напрямую", т.е. с preference OSPF/10 Но ведь даже, если не конфигурить shamlink, то они и так видят друг друга с preference OSPF/10, а не OSPF/150 за счёт передачи rte-type community через MP-BGP(при редистрибьюции из ospf в mp-bgp) Собственно вот вывод таблицы маршрутов без shamlink с CE-B: # run show route logical-system B8 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.10.0/24 *[OSPF/150] 00:22:36, metric 0, tag 3489726440 > to 10.0.11.1 via lt-1/2/0.83 10.0.11.0/24 *[Direct/0] 1d 01:50:30 > via lt-1/2/0.83 10.0.11.2/32 *[Local/0] 1d 01:50:30 Local via lt-1/2/0.83 !!!!192.168.11.1/32 *[OSPF/10] 00:22:36, metric 2 > to 10.0.11.1 via lt-1/2/0.83 192.168.11.2/32 *[Direct/0] 1d 01:51:58 > via lo0.8 224.0.0.5/32 *[OSPF/10] 00:28:06, metric 1 MultiRecv !!!! - помечен маршрут от CE-A # run show ospf database logical-system B8 OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 10.0.11.1 10.0.11.1 0x80000004 1308 0x22 0x6ee0 48 Router *192.168.11.2 192.168.11.2 0x80000004 1307 0x22 0xe485 60 !!!!Summary 192.168.11.1 10.0.11.1 0x80000001 1436 0xa2 0x2907 28 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern 10.0.10.0 10.0.11.1 0x80000002 213 0xa2 0x75d7 36 Т.е. префикс 192.168.11.1 распространяется с помощью LSA type 3 и поэтому имеет preference 10. Какой смысл тогда поднимать shamlink? Ну будет он распространяться как LSA type 1, preference-то от этого не изменится, метрика тоже. Зачем оно тогда нужно? По поводу rte-type community см. ниже: # run show route table bgp.l3vpn 192.168.11.1/32 extensive logical-system R3 bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 192.168.1.1:1:192.168.11.1/32 (1 entry, 0 announced) *BGP Preference: 170/-101 Route Distinguisher: 192.168.1.1:1 Next hop type: Indirect Address: 0x9260688 Next-hop reference count: 6 Source: 192.168.1.1 Next hop type: Router, Next hop index: 1782 Next hop: 172.22.212.2 via lt-1/2/0.32 weight 0x1, selected Label-switched-path to-R1 Label operation: Push 299920, Push 299776(top) Label TTL action: prop-ttl, prop-ttl(top) Protocol next hop: 192.168.1.1 Push 299920 Indirect next hop: 90d03a0 1048772 State: <Active Int Ext> Local AS: 65512 Peer AS: 65512 Age: 38:46 Metric: 1 Metric2: 2 Task: BGP_65512.192.168.1.1+179 AS path: I !!!!! Communities: target:65512:101 rte-type:0.0.0.0:1:0 Import Accepted VPN Label: 299920 Localpref: 100 Router ID: 192.168.1.1 Secondary Tables: vpn-a.inet.0 Indirect next hops: 1 Protocol next hop: 192.168.1.1 Metric: 2 Push 299920 Indirect next hop: 90d03a0 1048772 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 172.22.212.2 via lt-1/2/0.32 weight 0x1 192.168.1.1/32 Originating RIB: inet.3 Metric: 2 Node path count: 1 Forwarding nexthops: 1 Nexthop: 172.22.212.2 via lt-1/2/0.32 Конфиг R3 и CE-B ниже. R1 и CE-A аналогичны. # show logical-systems R3 interfaces { lt-1/2/0 { unit 32 { encapsulation ethernet; peer-unit 23; family inet { address 172.22.212.1/24; } family mpls; } unit 38 { encapsulation ethernet; peer-unit 83; family inet { address 10.0.11.1/24; } } } lo0 { unit 3 { family inet { address 192.168.1.3/32; } } } } protocols { rsvp { interface lt-1/2/0.32; } mpls { icmp-tunneling; no-cspf; label-switched-path to-R1 { to 192.168.1.1; } interface lt-1/2/0.32; } bgp { group int { type internal; local-address 192.168.1.3; family inet { unicast; } family inet-vpn { unicast; } export nh-self; remove-private; neighbor 192.168.1.1; } } ospf { area 0.0.0.0 { interface lo0.3 { passive; } interface lt-1/2/0.32 { interface-type p2p; } } } } policy-options { policy-statement nh-self { then { next-hop self; } } policy-statement vpn-a-bgp-to-ospf { from protocol bgp; then accept; } } routing-instances { vpn-a { instance-type vrf; interface lt-1/2/0.38; route-distinguisher 192.168.1.2:1; vrf-target target:65512:101; protocols { ospf { export vpn-a-bgp-to-ospf; area 0.0.0.0 { interface lt-1/2/0.38 { interface-type p2p; } } } } } } routing-options { autonomous-system 65512; } # show logical-systems B8 interfaces { lt-1/2/0 { unit 83 { encapsulation ethernet; peer-unit 38; family inet { address 10.0.11.2/24; } } } lo0 { unit 8 { family inet { address 192.168.11.2/32; } } } } protocols { ospf { area 0.0.0.0 { interface lt-1/2/0.83 { interface-type p2p; } interface lo0.8 { passive; } } } } policy-options { policy-statement exp-lo { from { route-filter 192.168.11.2/32 exact accept; } } } routing-options { autonomous-system 65101 loops 2; }

Да. Работает с ним! Спасибо. [edit logical-systems] # set R1 protocols mpls icmp-tunneling # set R2 protocols mpls icmp-tunneling # set R3 protocols mpls icmp-tunneling # commit # run traceroute 192.168.11.2 source 192.168.11.1 logical-system A7 traceroute to 192.168.11.2 (192.168.11.2) from 192.168.11.1, 30 hops max, 40 byte packets 1 10.0.10.1 (10.0.10.1) 0.472 ms 0.345 ms 0.348 ms 2 172.22.210.2 (172.22.210.2) 0.543 ms 0.419 ms 0.437 ms MPLS Label=299792 CoS=0 TTL=1 S=0 MPLS Label=299888 CoS=0 TTL=1 S=1 3 172.22.212.1 (172.22.212.1) 0.557 ms 0.409 ms 0.420 ms MPLS Label=299888 CoS=0 TTL=1 S=1 4 192.168.11.2 (192.168.11.2) 0.408 ms 0.540 ms 0.535 ms # run traceroute 192.168.11.2 routing-instance vpn-a logical-system R1 traceroute to 192.168.11.2 (192.168.11.2), 30 hops max, 40 byte packets 1 172.22.210.2 (172.22.210.2) 0.674 ms 0.461 ms 0.449 ms MPLS Label=299792 CoS=0 TTL=1 S=0 MPLS Label=299888 CoS=0 TTL=1 S=1 2 172.22.212.1 (172.22.212.1) 0.566 ms 0.422 ms 0.413 ms MPLS Label=299888 CoS=0 TTL=1 S=1 3 192.168.11.2 (192.168.11.2) 0.537 ms 0.544 ms 0.539 ms

Схему прилагаю. Делаю traceroute с CE-A или с R1, не вижу P-роутера в трассировке, вместо него звёздочки(A7=CE-A, B8=CE-B): # run traceroute 192.168.11.2 source 192.168.11.1 logical-system A7 traceroute to 192.168.11.2 (192.168.11.2) from 192.168.11.1, 30 hops max, 40 byte packets 1 10.0.10.1 (10.0.10.1) 0.334 ms 0.337 ms 0.324 ms 2 * * * 3 172.22.212.1 (172.22.212.1) 0.616 ms 0.413 ms 0.423 ms MPLS Label=299888 CoS=0 TTL=1 S=1 4 192.168.11.2 (192.168.11.2) 0.548 ms 0.533 ms 0.538 ms # run traceroute 192.168.11.2 routing-instance vpn-a logical-system R1 traceroute to 192.168.11.2 (192.168.11.2), 30 hops max, 40 byte packets 1 * * * 2 172.22.212.1 (172.22.212.1) 0.611 ms 0.447 ms 0.413 ms MPLS Label=299888 CoS=0 TTL=1 S=1 3 192.168.11.2 (192.168.11.2) 0.545 ms 0.547 ms 0.541 ms Помогите сделать так, чтобы P-роутер(R2) появился в трассировке. Конфиги: A7 { interfaces { lt-1/2/0 { unit 71 { encapsulation ethernet; peer-unit 17; family inet { address 10.0.10.2/24; } } } lo0 { unit 7 { family inet { address 192.168.11.1/32; } } } } protocols { bgp { group ext { export exp-lo; neighbor 10.0.10.1 { peer-as 65512; } } } } policy-options { policy-statement exp-lo { from { route-filter 192.168.11.1/32 exact accept; } } } routing-options { autonomous-system 65101; } } B8 { interfaces { lt-1/2/0 { unit 83 { encapsulation ethernet; peer-unit 38; family inet { address 10.0.11.2/24; } } } lo0 { unit 8 { family inet { address 192.168.11.2/32; } } } } protocols { bgp { inactive: traceoptions { file bgp-debug.log; flag all detail; } group ext { export exp-lo; neighbor 10.0.11.1 { peer-as 65512; } } } } policy-options { policy-statement exp-lo { from { route-filter 192.168.11.2/32 exact accept; } } } routing-options { autonomous-system 65101 loops 2; } } R1 { interfaces { lt-1/2/0 { unit 12 { encapsulation ethernet; peer-unit 21; family inet { address 172.22.210.1/24; } family mpls; } unit 17 { encapsulation ethernet; peer-unit 71; family inet { address 10.0.10.1/24; } } } lo0 { unit 1 { family inet { address 192.168.1.1/32; } } } } protocols { rsvp { interface lt-1/2/0.12; } mpls { no-cspf; label-switched-path to-R3 { to 192.168.1.3; } interface lt-1/2/0.12; } bgp { group int { type internal; local-address 192.168.1.1; family inet { unicast; } family inet-vpn { unicast; } export nh-self; remove-private; neighbor 192.168.1.3; } } ospf { area 0.0.0.0 { interface lo0.1 { passive; } interface lt-1/2/0.12 { interface-type p2p; } } } } policy-options { policy-statement nh-self { then { next-hop self; } } } routing-instances { vpn-a { instance-type vrf; interface lt-1/2/0.17; route-distinguisher 192.168.1.1:1; vrf-target target:65512:101; protocols { bgp { group ext { remove-private; neighbor 10.0.10.2 { peer-as 65101; } } } } } } routing-options { autonomous-system 65512; } } R2 { interfaces { lt-1/2/0 { unit 21 { encapsulation ethernet; peer-unit 12; family inet { address 172.22.210.2/24; } family mpls; } unit 23 { encapsulation ethernet; peer-unit 32; family inet { address 172.22.212.2/24; } family mpls; } } lo0 { unit 2 { family inet { address 192.168.1.2/32; } } } } protocols { rsvp { interface lt-1/2/0.21; interface lt-1/2/0.23; } mpls { interface lt-1/2/0.21; interface lt-1/2/0.23; } ospf { area 0.0.0.0 { interface lo0.2 { passive; } interface lt-1/2/0.21 { interface-type p2p; } interface lt-1/2/0.23 { interface-type p2p; } } } } } R3 { interfaces { lt-1/2/0 { unit 32 { encapsulation ethernet; peer-unit 23; family inet { address 172.22.212.1/24; } family mpls; } unit 38 { encapsulation ethernet; peer-unit 83; family inet { address 10.0.11.1/24; } } } lo0 { unit 3 { family inet { address 192.168.1.3/32; } } } } protocols { rsvp { interface lt-1/2/0.32; } mpls { no-cspf; label-switched-path to-R1 { to 192.168.1.1; } interface lt-1/2/0.32; } bgp { group int { type internal; local-address 192.168.1.3; family inet { unicast; } family inet-vpn { unicast; } export nh-self; remove-private; neighbor 192.168.1.1; } } ospf { area 0.0.0.0 { interface lo0.3 { passive; } interface lt-1/2/0.32 { interface-type p2p; } } } } policy-options { policy-statement nh-self { then { next-hop self; } } } routing-instances { vpn-a { instance-type vrf; interface lt-1/2/0.38; route-distinguisher 192.168.1.2:1; vrf-target target:65512:101; protocols { bgp { group ext { remove-private; neighbor 10.0.11.2 { peer-as 65101; } } } } } } routing-options { autonomous-system 65512; } } Заранее спасибо! Не загрузилась схема. http://img13.imageshack.us/img13/1219/8j41.png

orlik Спасибо!

Конфиг: # show logical-systems R4 protocols mpls static-label-switched-path my-lsp { transit 1000515 { next-hop 172.40.0.2; pop; } } static-label-switched-path my-lsp2 { transit 1000030 { next-hop 172.30.0.1; swap 1000130; } } interface lt-1/2/0.42; interface lt-1/2/0.45; Таблица mpls.0: # run show route logical-system R4 table mpls.0 mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0 *[MPLS/0] 00:26:10, metric 1 Receive 1 *[MPLS/0] 00:26:10, metric 1 Receive 2 *[MPLS/0] 00:26:10, metric 1 Receive 1000030 *[MPLS/6] 00:09:23, metric 1 > to 172.30.0.1 via lt-1/2/0.42, Swap 1000130 1000515 *[MPLS/6] 00:22:33, metric 1 > to 172.40.0.2 via lt-1/2/0.45, Pop 1000515(S=0) *[MPLS/6] 00:22:33, metric 1 > to 172.40.0.2 via lt-1/2/0.45, Pop В чём смысл записи 1000515(S=0) и чем она отличается от 1000515? # run show route logical-system R4 table mpls.0 label 1000515 extensive mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) 1000515 (1 entry, 1 announced) TSI: KRT in-kernel 1000515/52 -> {Pop } *MPLS Preference: 6 Next hop type: Router, Next hop index: 1841 Address: 0x9240250 Next-hop reference count: 2 Next hop: 172.40.0.2 via lt-1/2/0.45 weight 0x1, selected Label operation: Pop State: <Active Int> Age: 23:31 Metric: 1 Task: MPLS Announcement bits (1): 1-KRT AS path: I 1000515(S=0) (1 entry, 1 announced) TSI: KRT in-kernel 1000515/56 -> {Pop } *MPLS Preference: 6 Next hop type: Router, Next hop index: 1842 Address: 0x9240298 Next-hop reference count: 2 Next hop: 172.40.0.2 via lt-1/2/0.45 weight 0x1, selected Label operation: Pop State: <Active Int> Age: 23:31 Metric: 1 Task: MPLS Announcement bits (1): 1-KRT AS path: I Заранее всем спасибо.

orlik Спасибо за отклик. Карты mpc-шные. сейчас обнаружил, что IRB вообще не работает на бриджах, собранных из lt. как же не хочется ехать в эту серверную...

Конфиг(используется оборудование MX): # show bridge-domains vlan_100 { vlan-id 100; } # show interfaces lt-1/3/0 unit 0 { encapsulation ethernet; peer-unit 1; family inet { address 1.1.1.1/30; } } unit 1 { encapsulation ethernet-bridge; peer-unit 0; family bridge { interface-mode access; vlan-id 100; } } unit 2 { encapsulation ethernet-bridge; peer-unit 3; family bridge { interface-mode access; vlan-id 100; } } unit 3 { encapsulation ethernet; peer-unit 2; family inet { address 1.1.1.2/30; } } # show routing-instances test1 instance-type virtual-router; interface lt-1/3/0.0; # show routing-instances test2 instance-type virtual-router; interface lt-1/3/0.3; Сразу же смотрим мак-таблицу: # run show bridge mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : default-switch Bridging domain : vlan_100, VLAN : 100 MAC MAC Logical address flags interface 18:29:17:05:a2:41 S,NM lt-1/3/0.2 Не совсем понятно зачем этот статический мак-адрес нужен. Запускаем ping: # run ping routing-instance test2 1.1.1.1 source 1.1.1.2 PING 1.1.1.1 (1.1.1.1): 56 data bytes ^C --- 1.1.1.1 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss не работает, в мак-таблице тоже самое что и было Если же запустить в обратную сторону, то пингуется: # run ping routing-instance test1 1.1.1.2 source 1.1.1.1 PING 1.1.1.2 (1.1.1.2): 56 data bytes 64 bytes from 1.1.1.2: icmp_seq=0 ttl=64 time=0.678 ms 64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.561 ms ^C --- 1.1.1.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.561/0.620/0.678/0.059 ms В мак-таблице появляется вторая запись: # run show bridge mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : default-switch Bridging domain : vlan_100, VLAN : 100 MAC MAC Logical address flags interface 18:29:17:05:a2:40 D lt-1/3/0.1 18:29:17:05:a2:41 S,NM lt-1/3/0.2 И после этого неработающий пинг работает: # run ping routing-instance test2 1.1.1.1 source 1.1.1.2 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=64 time=33.597 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=38.144 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=32.196 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=31.669 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=30.923 ms Но с большими задержками почему-то. Это нормальное поведение? Можно как-то сделать, чтоб первый ping сразу работал? Есть ли смысл делать лабы по свитчингу на логических тунелях? Без реального патчкорда не обойтись?

Помогите осилить вот это: Насколько я вижу, по умолчанию(если не настраивать балансировку), выбирается один nexthop для каждого префикса. Тогда не понимаю в чём разница(с точки балансировки без доп. настроек) между IGP и BGP? Вот например префиксы, полученные по ospf по двум equal-cost линкам: root@r2# run show route .... 1.1.1.3/32 *[OSPF/10] 00:08:06, metric 1 to 172.16.10.1 via em1.10 > to 172.16.20.1 via em1.20 1.1.2.3/32 *[OSPF/10] 00:08:06, metric 1 to 172.16.10.1 via em1.10 > to 172.16.20.1 via em1.20 1.1.3.3/32 *[OSPF/10] 00:08:06, metric 1 > to 172.16.10.1 via em1.10 to 172.16.20.1 via em1.20 1.1.4.3/32 *[OSPF/10] 00:08:06, metric 1 to 172.16.10.1 via em1.10 > to 172.16.20.1 via em1.20 1.1.5.3/32 *[OSPF/10] 00:08:06, metric 1 to 172.16.10.1 via em1.10 > to 172.16.20.1 via em1.20 1.1.6.3/32 *[OSPF/10] 00:08:06, metric 1 > to 172.16.10.1 via em1.10 to 172.16.20.1 via em1.20 ... root@r2# run show route forwarding-table ... 1.1.1.3/32 user 0 172.16.20.1 ucst 553 15 em1.20 1.1.2.3/32 user 0 172.16.20.1 ucst 553 15 em1.20 1.1.3.3/32 user 0 172.16.10.1 ucst 549 9 em1.10 1.1.4.3/32 user 0 172.16.20.1 ucst 553 15 em1.20 1.1.5.3/32 user 0 172.16.20.1 ucst 553 15 em1.20 1.1.6.3/32 user 0 172.16.10.1 ucst 549 9 em1.10 Чем это не per-prefix load balancing, о котором говорится в пункте про bgp?

j@x спасибо! вопрос снят

мне нужно понять как оно работает... В данном случае у ::/0 есть 3 contributing routes: Почему-то берётся nexthop маршрута 2001::/62. Это просто рандом или есть какой-то критерий?

Добрый день Есть топология r1 em0 <-> r2 em0 (em0 потому что эмуляция, а не настоящий juniper) Не понимаю по какому принципу выбирается nexthop для generated route: root@r2# run show route ::/0 exact extensive inet6.0: 11 destinations, 12 routes (11 active, 0 holddown, 0 hidden) ::/0 (1 entry, 1 announced) TSI: KRT in-kernel ::/0 -> {2000::1} *Aggregate Preference: 130 Next hop type: Router, Next hop index: 548 Address: 0x9334178 Next-hop reference count: 4 Next hop: 2000::1 via em0.10, selected State: <Active Int Ext> Local AS: 18 Age: 2:19:35 Task: Aggregate Announcement bits (1): 0-KRT AS path: I Flags: Generate Depth: 0 Active Contributing Routes (3): 2001::/62 proto BGP 2a00:2::/63 proto BGP 2a00:2::1/128 proto BGP Почему выбирается 2000::1 via em0.10 ? root@r2# run show route inet6.0: 11 destinations, 12 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both ::/0 *[Aggregate/130] 02:20:22 > to 2000::1 via em0.10 2000::/127 *[Direct/0] 00:54:25 > via em0.10 2000::/128 *[Local/0] 00:54:25 Local via em0.10 2000:1::/127 *[Direct/0] 00:54:25 > via em0.20 2000:1::/128 *[Local/0] 00:54:25 Local via em0.20 2001::/62 *[bGP/170] 00:12:04, localpref 100 AS path: 196613 I > to 2000::1 via em0.10 2a00:2::/63 *[bGP/170] 00:12:00, localpref 100 AS path: 196613 I > to 2000:1::1 via em0.20 2a00:2::1/128 *[bGP/170] 00:12:00, localpref 100 AS path: 196613 I > to 2000:1::1 via em0.20 fe80::/64 *[Direct/0] 00:54:25 > via em0.10 [Direct/0] 00:54:25 > via em0.20 fe80::2ab:b100:ac4:7200/128 *[Local/0] 00:54:25 Local via em0.10 fe80::2ab:b100:14c4:7200/128 *[Local/0] 00:54:25 Local via em0.20 root@r2# show ## Last changed: 2013-08-28 16:51:33 UTC version 12.1R1.9; system { host-name r2; root-authentication { encrypted-password "$1$62gr6sV1$U4Qu7LpE7lCCQJMYgJTMm1"; ## SECRET-DATA } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } } } interfaces { em0 { vlan-tagging; unit 10 { vlan-id 10; family inet6 { address 2000::0/127; } } unit 20 { vlan-id 20; family inet6 { address 2000:1::0/127; } } } em1 { disable; } } routing-options { rib inet6.0 { generate { route ::/0; } } router-id 1.1.1.2; autonomous-system 18; } protocols { bgp { group ext { type external; neighbor 2000::1 { peer-as 3.5; } neighbor 2000:1::1 { peer-as 3.5; } } } } [edit] root@r1# show ## Last changed: 2013-08-28 17:31:01 UTC version 12.1R1.9; system { host-name r1; root-authentication { encrypted-password "$1$lWW6LJkL$chJ5dkjYDoD1OZ6SpvQP0/"; ## SECRET-DATA } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } } } interfaces { em0 { vlan-tagging; unit 10 { vlan-id 10; family inet6 { address 2000::1/127; } } unit 20 { vlan-id 20; family inet6 { address 2000:1::1/127; } } } em1 { disable; } em4 { disable; } lo0 { unit 0 { family inet6 { address 2001::1/62; address 2a00:2::1/63 { preferred; } } } } } routing-options { rib inet6.0 { static { inactive: route 2001::0/64 reject; } } router-id 1.1.1.1; autonomous-system 3.5; } protocols { bgp { inactive: traceoptions { file bgp.log; flag all; } group ext { type external; neighbor 2000::0 { export bgp-ext-1; peer-as 18; } neighbor 2000:1::0 { export bgp-ext-2; peer-as 18; } } } } policy-options { policy-statement bgp-ext-1 { term 1 { from { route-filter 2001::0/62 exact accept; } } } policy-statement bgp-ext-2 { term 1 { from { route-filter 2a00:2::/63 orlonger accept; } } } } [edit] Если с r1 вместо 2001::/62 анонсировать 2001::/64, то всё равно nexthop-ом для v6-дефолта выбирается 2000::1 via em0.10