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]