This article explains the behavior of using chained-composite-next-hop along with Inter-AS option B scenario.
Inter-AS option B scenario is running in the network. Due to certain customer requirements and improved scalability, 'chained-composite-next-hop' is implemented in this network. A chained composite next hop allows the router to direct sets of routes, sharing the same destination to a common forwarding next hop rather than having each route also include the destination. Please refer to Juniper documentation on chained-composite-next-hop for more details. After adding the knob, routes received from peer ASBR are hidden and not installed in the routing table. Below is the topology for Inter-AS VPN.
AS1 AS2
CE1 ------ PE1 ------ ASBR1------ ASBR2 ------- PE2 ------ CE2
Below is the minimum configuration on ASBR1:
set interfaces ge-1/0/0 unit 0 family inet address 10.10.10.1/24 <-- Towards ASBR2 set interfaces ge-1/0/0 unit 0 family mpls set interfaces ge-1/0/1 unit 0 family inet address 192.168.10.2/24 <-- Towards PE1 set interfaces ge-1/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 2.2.2.2/32 set protocols bgp group inter-as type external set protocols bgp group inter-as family inet-vpn unicast set protocols bgp group inter-as family inet-vpn multicast set protocols bgp group inter-as family inet6-vpn unicast set protocols bgp group inter-as peer-as 7822 set protocols bgp group inter-as neighbor 10.10.10.2 <-- Physical interface peering towards ASBR2 set protocols bgp group ibgp type internal set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 1.1.1.1 local-address 2.2.2.2 set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface ge-1/0/1.0 set protocols ldp interface lo0.0
Corresponding configuration from ASBR2 is not shown here in this example. The following VPN route is received from ASBR2(10.10.10.2) on ASBR1:
root@R2_re# run show route receive-protocol bgp 10.10.10.2 inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden) inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) bgp.l3vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 10.10.10.2:7:192.168.20.0/24 * 10.10.10.2 7822 I inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) [edit routing-options]
If we look closely, this route has a direct next-hop which is resolved in inet.0
root@R2_re# run show route 192.168.20/24 extensive bgp.l3vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 10.10.10.2:7:192.168.20.0/24 (1 entry, 1 announced) TSI: Page 0 idx 1, (group ibgp type Internal) Type 1 val 0x9757a84 (adv_entry) Advertised metrics: Flags: Nexthop Change Nexthop: Self Localpref: 100 AS path: [7821] 7822 I Communities: target:9000:100 VPN Label: 299808 Path 10.10.10.2:7:192.168.20.0 from 10.10.10.2 Vector len 4. Val: 1 *BGP Preference: 170/-101 Route Distinguisher: 10.10.10.2:7 Next hop type: Router Address: 0x9784150 Next-hop reference count: 2 Source: 10.10.10.2 Next hop: 10.10.10.2 via ge-1/0/0.0, selected Label operation: Push 16 Label TTL action: prop-ttl Load balance label: Label 16: None; Session Id: 0x0 State: <Active Ext ProtectionPath ProtectionCand> Local AS: 7821 Peer AS: 7822 Age: 3:37 Validation State: unverified Task: BGP_7822.10.10.10.2+179 Announcement bits (1): 0-BGP_RT_Background AS path: 7822 I Communities: target:9000:100 Accepted VPN Label: 16 Localpref: 100 Router ID: 128.102.243.166 [edit routing-options] root@R2_re# run show route 10.10.10.2 inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/24 *[Direct/0] 00:05:47 > via ge-1/0/0.0 [edit routing-options]
Now, chained-composite-next-hop is added to the configuration and observe the behavior:
root@R2_re# top show routing-options forwarding-table chained-composite-next-hop { transit { l3vpn; } }
Once the configuration is committed, verify the received route again.
[edit routing-options] root@R2_re# run show route hidden extensive inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden) inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) bgp.l3vpn.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden) 10.10.10.2:7:192.168.20.0/24 (1 entry, 0 announced) BGP Preference: 170/-101 Route Distinguisher: 10.10.10.2:7 Next hop type: Unusable Address: 0x9421a64 Next-hop reference count: 1 State: <Hidden Ext ProtectionPath ProtectionCand> Local AS: 7821 Peer AS: 7822 Age: 1:24 Validation State: unverified Task: BGP_7822.10.10.10.2+179 AS path: 7822 I Communities: target:9000:100 Accepted VPN Label: 16 Localpref: 100 Router ID: 128.102.243.166 Indirect next hops: 1 Protocol next hop: 10.10.10.2 Label operation: Push 16 Label TTL action: prop-ttl Load balance label: Label 16: None; Indirect next hop: 0x0 - INH Session ID: 0x0
root@R2_re# run show route 10.10.10.2 inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/24 *[Direct/0] 00:12:22 > via ge-1/0/0.0
The next-hop is changed to Indirect next-hop, and the route is no-more resolved via inet.0 though we still have the direct route.
The behavior seen above is an expected behavior. Once the chained-composite-next-hop is configured, the route will change to indirect-route. This Indirect route is required to be resolved via inet.3 One way to achieve this is using rib-groups:
set routing-options interface-routes rib-group inet direct-to-inet3 set routing-options rib-groups direct-to-inet3 import-rib inet.0 set routing-options rib-groups direct-to-inet3 import-rib inet.3 set routing-options rib-groups direct-to-inet3 import-policy import-direct set policy-options policy-statement import-direct term 1 from protocol direct set policy-options policy-statement import-direct term 1 from route-filter 10.10.10.0/24 exact set policy-options policy-statement import-direct term 1 then accept set policy-options policy-statement import-direct term 2 then reject
After the changes, next-hop route is leaked to inet.3 and indirect route is able to resolve next-hop and active again.
root@R2_re# run show route 10.10.10.2 inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/24 *[Direct/0] 00:19:36 > via ge-1/0/0.0 inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/24 *[Direct/0] 00:00:03 > via ge-1/0/0.0 root@R2_re# run show route 192.168.20/24 bgp.l3vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.2:7:192.168.20.0/24 *[BGP/170] 00:10:08, localpref 100 AS path: 7822 I, validation-state: unverified > to 10.10.10.2 via ge-1/0/0.0, Push 16 [edit routing-options]