[Junos] Chained composite next-hop behavior with Inter-AS VPN 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]

Knowledge Base